- lir-wg - mailman.ripe.net

Re: pro/cons of virtual hosting services
by jcaron＠pressimage.net 27 Nov '95

27 Nov '95

At 17:17 14/11/95, Daniel Karrenberg wrote: > > poole(a)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(a)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

5 4

Announcement for Local IR Training Course in Amsterdam
by RIPE NCC Training 20 Nov '95

20 Nov '95

* * * Announcement * * * Local Internet Registries Training Course Date: Thursday, 1. February, 1996 Time: 0900 - 1700 Venue: RIPE NCC Kruislaan 409 1098 SJ Amsterdam The Netherlands Course Audience --------------- The target audience for this course is personnel of European Local Internet Registries that contribute to the RIPE NCC. Material Covered ---------------- The course is a one day introduction on Internet name, address and routing policy registration procedures in Europe. It also teaches how to query and use the information registered for operational purposes. This includes the following material and activities: o Overview of name, address and routing registration procedures. o Responsibilities of both RIPE NCC and Local IR's to each other. o Wider context of the Delegated Registry system and relevant issues (IPv4 address depletion, CIDR) and how this relates to IP requests. o How to use the RIPE NCC Database. o Use of AS numbers, Routing Registry concepts and an introduction to using PRIDE tools. o DNS feedback on commor errors, how to request delegations, and pointers to useful tools. We again stress that this course will *not* teach Local Registries on how to run their business as Internet Service Providers. It is clearly focussed on registration procedures and the interaction between the RIPE NCC and local IR's. A detailed outline is appended below. The course itself will include lunch and will be free. This of course does not include your travel and subsitence ;-). How to Register --------------- Please send an RSVP to <training(a)ripe.net> if you would like to attend the course. If you have previously approached us about attending this course, we ask you to confirm that you (or a colleague) will be attending. Registrations will be accepted on a first come, first served basis. If the course is oversubscribed, we will give priority to local IRs who have paid the signup fee in 1995. If it is still oversubscribed, we will accept only one person per new local registry. We will provide additional course dates in Amsterdam as necessary. If a number of local registries so request, we will present courses at other European locations. If you would like a local course or have any questions or suggestions, please do not hesitate to contact us. The RIPE NCC Training Team: Mirjam Kuehne, Daniel Karrenberg --- Course Outline -------------- For this second course, we will provide a slidebook and a reader on the day of the course, as well as electronically. Once feedback is received, it is planned to make detailed documentation available in the form of a guide much like the PRIDE guide. The program will divide the actual content into the following sections: 1. Introduction For those unfamiliar with the Delegated Internet Registry system and the RIPE NCC, this section will give a historical overview of how we have arrived at today's model of operation and why training of local IR's is a much needed activity. 2. IP Registry procedures This section will clarify the procedures between the RIPE NCC and local IR's with respect to requests for IP address space. It will take a step by step approach on how to complete documentation, the kind of information that is required, what the "handholding" procedure is, how to deal with very large requests, and very small requests, and more generally what criteria the RIPE NCC and local IR's use for their customers in the context of CIDR and IPv4 address depletion. 3. RIPE NCC Database This section will explain what the RIPE NCC Database is and how it fits into the scheme of other registry databases. It will cover how to create and update RIPE NCC Database objects and will explain how to query the database. 4. Routing Registry procedures This section will examine AS numbers, when you need them and how to request them. This will be set within the context of how AS numbers are used as part of the RIPE Routing Registry. Understanding the basic principles behind the Internet Routing Registry and how registering your policy is an important element in the global schema. This section will also include a brief introduction to the PRIDE tools and how they can be useful to you. 5. DNS procedures Where to request forward and reverse domain delegation. Which documentation should be completed. How reverse domain delegation requests are processed at the RIPE NCC (with a useful tool). We will also take a look at common errors in setting up DNS with respect to relevant RFCs and RIPE recommendations. Feedback Please! Throughout the course there will be ample chance for feedback and discussion with an emphasis for you to tell us how we can improve ;-). %%%%%%%%%%% PLEASE NOTE %%%%%%%%%%% Our handling of ALL course registrations is fully automated. To register for the course, please complete the registration form and send it to <training(a)ripe.net>. Please send only the registration form in your reply and edit out all other text. Add in a value in the `box' area marked between the square brackets (i.e. "[" and "]" s). If you have any questions about the training course or your registration form, please contact us at <training(a)ripe.net>. You will receive a notification message that your request has been processed. Many thanks, and look forward to seeing you, RIPE NCC Training Team ---------------------------------------------------------------------------- %START PART 1 - Registration 1) Your name Enter First name, Last name in FULL e.g. John Doe Mary-Beth Walton # NAME [ ] 2) Your Registry ID (format: country-code.<name of registry>) # REG [ ] 3) Your e-mail address # EMAIL [ ] 4) The course you plan to attend (date and location) # COURSE [ ] %END

1 0

Virtual Web Hosting Services
by David Guthrie 19 Nov '95

19 Nov '95

Daniel, We strongly support Peter Galbavy's position on web hosting services and that using a single ip address is not bad! The Internet's growth and success have made it crucial for any good sized company to have a presence on the Web. The alternatives are usually to install a leased line, router and web server which would usually take up a much larger subnet or even a full class C address or to use a web hosting service of some sort that uses only a single ip address for an entire company. This is clearly much more efficient that each Web site using a larger address space assignment and thereby placing greater strain on the diminishing address pool. Large companies have lots of budget and if they can't get the lower cost shared web server solution, they will opt for the higher solution. Our experience is that they will not tolerate the www.provider.xx/~yourco sort of addressing convention. Great, however for individuals. Birds of a feather like to fly together. Most of the big birds have their own www.yourco.xx registations and now the smaller ones now want the same sort of presentation. The designers of http should perhaps have thought this out or get thinking about a solution. In the meantime the rest of us have to find a way to make it work the most efficiently. Regards David Guthrie, Technocom plc, U.K.

3 2

Valid Use [was pro/cons of virtual hosting]
by Oliver Smith 17 Nov '95

17 Nov '95

I wish to propose that RIPE produce a document defining acceptable use of an IP address. I'm not sure which of the lists is the most apropriate, but I'm sure discussion can be moved to the relevant group. I believe such a document would be beneficial to the RIPE NCC community as a whole. Regards, Oliver Smith

1 0

RE: Routing wars pending?
by Hank Nussbacher 16 Nov '95

16 Nov '95

On Wed, 15 Nov 1995 11:00:04 MET you said: > With regard to the rest of your message - here is what we do, both as a > Service Provider Registry and a as backbone provider which has to deal > with routing: > > We strictly refuse requests to assign address space for further > sub-assignement. Adresses are *directly* assigned to the eventual user. > If a service provider wants to act as a Local-IR, then the proper way > of doing it is to get in touch with the RIPE-NCC and establish a > registry of it's own. Is that the general consensus in other countries? > > Just to make sure that everybody understands the rules, we explicitely > point out that the assignement is only valid for the purpose of > connecting (directly or through an intermediate step) to our backbone. > We explicitely reserve the right to reclaim the address space if these > conditions are not (or no longer) met. I know that RLR are slightly > different, of course. We have had problems with this also. > > With regard to routing, the answer is both collaboration by all > service providers (which is working rather well, I think) *and* > filtering based on the route objects in the RIPE database (which > appears to gain popularity). If somebody tries to play games, and most > of the backbones would have filters, then there is a good chance that > the hickup is confined to a small part of the Internet - which > eventually makes the "highjacked" addresses more or less useless. Yes Europe is very organized - but what do you do about the USA? > > And the multiple database issue should be sorted out anyway, because > the problem of inconsistency *is* there, even without malicious intent > on any side. > > Wilfried. > -------------------------------------------------------------------------- > Wilfried Woeber : e-mail: Woeber(a)CC.UniVie.ac.at > Computer Center - ACOnet : > Vienna University : Tel: +43 1 4065822 355 > Universitaetsstrasse 7 : Fax: +43 1 4065822 170 > A-1010 Vienna, Austria, Europe : NIC: WW144 > -------------------------------------------------------------------------- Hank

2 1

RE: PRO/CONS OF VIRTUAL HOSTING SERVICES
by 116780＠ibmmail.com 16 Nov '95

16 Nov '95

Daniel writes: >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". I'm sorry, but I cannot agree with this. For those companies who are using or wish to use the WWW for marketing purposes, it is a question of following what is *already* established practice and being on an equal footing with other companies. (I'm not pleading special interest - We are in the process of moving from a virtual host on an "WWW Hotel" to a new dedicated server of our own - no address space is thus freed up.) Andrew J Cowie Royal Insurance plc (http://www.royal-group.com/) Extra X400 information begins: Originator Name: COWIEA Org Units: LIVERPOOL Organisation: NHP Domain: GB/IBMX400/ROYINT Node.Userid: IBMX400.116780 Message Id: 0002C9A6.MAI Sent by Name: COWIEA Org Units: LIVERPOOL Organisation: NHP Domain: GB/IBMX400/ROYINT Node.Userid: IBMX400.116780 Free Fmt Name: COWIE, Andrew / NHP Subject: RE: PRO/CONS OF VIRTUAL HOSTING SERVICES Recipients Name: INET INET Domain: GB/IBMX400/IBMMAIL Node.Userid: IBMMAIL.INET Free Fmt Name: INET, INET Reply request: No

1 0

pro/cons of virtual hosting services
by Daniel Karrenberg 15 Nov '95

15 Nov '95

Dear colleagues, The following questions raises a current problem. Please take note. > luc(a)inbe.net (Luc Dierckx) writes: > > > Hello, > > Does RIPE have any opinions about the use of multiple IP addresses for > virtual hosting services ? (So using ifconfig ep0 alias, ifconfig ef0:1, > ifconfig vif0 ... not using different physical machines on the same > network) > > Technically, this is just a waste of IP addresses and pollution of the > naming space just for the 'niceness' of the URL. (http://www.customer.com/ > instead of http://www.provider.net/customer/ or aliased via > http://www.customer.country/customer/ ) > > Commercially, it's just another sales argument: 'Yes, we can offer you > http://www.company.com/'. > > Today INnet do not support the virtual hosting > but commercial pressure is up. I feel this needs immediate attention. > Unless there is really no problem with it. > If yes, it should be brought to every one's attention. 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. We recommend to use URLs of the form http://www.www-provider.com/customer1/ http://www.www-provider.com/customer2/ or if customers desire www.customer.com: http://www.customer1.com/customer1/ http://www.customer2.com/customer2/ with CNAME RRs for www.customer1.com and www.customer2.com pointing to the real server. The latter variant provides mobility for the customer without using extra address space. If you have any further questions, please do not hesitate to contact us. Regards Daniel Karrenberg RIPE NCC Manager

11 19

RE: Routing wars pending?
by Wilfried Woeber, UniVie/ACOnet 15 Nov '95

15 Nov '95

Hi Hank! I don't know to what extent you have been following the discussions recently within RIPE wrt Registries of Last Resort... My first answer to the story below would be "stop the Registry of Last Resort business asap". Just to avoid making the mess even bigger... >ILAN acts as registry of last resort in Israel. It owns and assigns >IP addresses in the 192.114-118.0.0 address range. These 5 blocks >are owned by ILAN (AS378). Over the years, many IP addresses have >been assigned - in the past to individual companies and more lately >CIDR blocks to local ISPs. ILAN takes a $50 one time fee to register >the IP address for the requestor. Just a matter of terminology, I'm worried by your mixing of the LRL function and phrases like "owns and assigns" in the same sentence with "owned by ILAN (AS378)". If you were really sending these signals to your peers then there is a good chance of mis-understandings. With regard to the rest of your message - here is what we do, both as a Service Provider Registry and a as backbone provider which has to deal with routing: We strictly refuse requests to assign address space for further sub-assignement. Adresses are *directly* assigned to the eventual user. If a service provider wants to act as a Local-IR, then the proper way of doing it is to get in touch with the RIPE-NCC and establish a registry of it's own. Just to make sure that everybody understands the rules, we explicitely point out that the assignement is only valid for the purpose of connecting (directly or through an intermediate step) to our backbone. We explicitely reserve the right to reclaim the address space if these conditions are not (or no longer) met. I know that RLR are slightly different, of course. With regard to routing, the answer is both collaboration by all service providers (which is working rather well, I think) *and* filtering based on the route objects in the RIPE database (which appears to gain popularity). If somebody tries to play games, and most of the backbones would have filters, then there is a good chance that the hickup is confined to a small part of the Internet - which eventually makes the "highjacked" addresses more or less useless. And the multiple database issue should be sorted out anyway, because the problem of inconsistency *is* there, even without malicious intent on any side. Wilfried. -------------------------------------------------------------------------- Wilfried Woeber : e-mail: Woeber(a)CC.UniVie.ac.at Computer Center - ACOnet : Vienna University : Tel: +43 1 4065822 355 Universitaetsstrasse 7 : Fax: +43 1 4065822 170 A-1010 Vienna, Austria, Europe : NIC: WW144 --------------------------------------------------------------------------

1 0

RE: PRO/CONS OF VIRTUAL HOSTING SERVICES
by 116780＠ibmmail.com 15 Nov '95

15 Nov '95

>"Wasting" this space enables the use of URLs like: > http://user.domain.foo/ > >While your suggestion will only enable URLs like: > http://user.domain.foo/bar/ >or http://user.domain.foo/~bar/ > >From a marketing point of view it makes A LOT of difference. >I wouldn't call it "wasting" address space. I would preffer the term >"utilizing" address space. Exactly - we have gone to a lot of trouble to set up an URL of the form http://company.com/, precisely because we want *our* customers to get to *our* pages in a transparent and intuitive way. Daniel's suggested method would require either that: 1. the address published is "messy" (eg http://company.com/company/), which would put us at a competitive disadvantage (ie others already have http://other_co.com/), and is counter-intuitive to established practice, or 2. the customer goes through a provider-specific index page, which may have links to very many (probably entirely unrelated) sites. Neither is acceptable for marketing reasons - Marketing may be a dirty word in some quarters, but IMHO it's here to stay, and it pays the bills. Andrew J Cowie Royal Insurance plc (http://royal-group.com/) Extra X400 information begins: Originator Name: COWIEA Org Units: LIVERPOOL Organisation: NHP Domain: GB/IBMX400/ROYINT Node.Userid: IBMX400.116780 Message Id: 0002C1C3.MAI Sent by Name: COWIEA Org Units: LIVERPOOL Organisation: NHP Domain: GB/IBMX400/ROYINT Node.Userid: IBMX400.116780 Free Fmt Name: COWIE, Andrew / NHP Subject: RE: PRO/CONS OF VIRTUAL HOSTING SERVICES Recipients Name: INET INET Domain: GB/IBMX400/IBMMAIL Node.Userid: IBMMAIL.INET Free Fmt Name: INET, INET Reply request: No

1 0

Re: pro/cons of virtual hosting services
by jcaron＠pressimage.net 14 Nov '95

14 Nov '95

At 18:25 14/11/95, poole(a)eunet.ch wrote: >> > Naturally the correct solution would be for the HTTP protocol to pass >> > the complete URL to the server, however it's too late for that. >> >> Which I understand is fixed in the newest spec. As far as I know, it is not in HTTP/1.0 (which is the formalization of current practice), neither in HTTP/1.1 (which is what the WG is working on). It should be in 1.2. Maybe it has been bumped to 1.1, which would be good news. >The problem is that I don't believe anybody that is -serious- about his >server advertizing (for lots of money) http://www.xyz.com/ if it is >not going to work with a -very- high percentage of browsers. The problem is that we need a transition period, in which we can continue to do virtual hosting, but have new browsers (and new versions of existing browsers) sending the new header anyway, even if it's not used by servers. When we reach a point where we have enough HTTP/1.whatever-compliant browsers, we can stop using virtual hosting. But for this to work, we have to start this transition period as soon as possible. Given the growth of the Internet user base at the moment, I guess that 80 or 90% of the users a year from now will be new users using new browsers, and most of the rest will have switched. But if we start doing this once the user base stops expanding that fast, it'll be A LOT harder. Jacques. --- Jacques Caron - Pressimage Telematique - jcaron(a)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

1 0