From GeertJan.deGroot at ripe.net Wed Nov 1 19:47:43 1995 From: GeertJan.deGroot at ripe.net (Geert Jan de Groot) Date: Wed, 01 Nov 1995 19:47:43 +0100 Subject: Disk problems at the NCC Message-ID: <9511011847.AA00639@ncc.ripe.net> Dear Local Registries Contacts, Thuesday oct 31 between 20.00 and 24.00, the RIPE NCC suffered a disk crash. The harddisk involved contained most of the data used for day-to-day operations, the maillist aliases (needed to contact you :-( and the mail spool directory. People who tried to contact us today may have found that they were unable to reach us. We apologise for any inconvienence caused by this; unfortunately, rebuilding the disk from backups took considerable time. Unfortunately we couldn't avoid any data loss. Mail that has been sent or processed between 12:00-24:00 at October 31st might be lost. We would appreciate if you could resent any mail you sent/received to/from us during this period with the line RESEND in the subject field. We will investigate our sendmail logs tomorrow and contact you directly if we can find traces of possible lost mail. As the RIPE NCC manager explained at the last RIPE meeting we are currently investigating the use of other hardware solutions to avoid this kind of problems in the future. Unfortunately, these plans had not materialized in time to prevent yesterday's incident. If you have any further questions, please don't hesitate to contact us at: Kind regards, Geert Jan de Groot David Kessens RIPE NCC From Mirjam.Kuehne at ripe.net Thu Nov 2 11:28:57 1995 From: Mirjam.Kuehne at ripe.net (Mirjam Kuehne) Date: Thu, 02 Nov 1995 11:28:57 +0100 Subject: New Expiry Date for ripe-128 and ripe-129 Message-ID: <9511021028.AA07636@ncc.ripe.net> Dear Local IR's, The following two documents have expired at 31 October 1995: ripe-128: Supporting Notes for European IP Address Space Requests ripe-129: European IP Address Space Request Form We have changed the exiry date to the 29. February 1996. Please note that the contents of the documents have not changed. The document ripe-104 "European Internet Registry: IP Address Space Assignment Procedures" is currently under revision. It is planned to publish the new version of this document at the next RIPE Meeting in January. As the Assignment Procedures will also have an effect on the Address Space Request Form, we have decided to postpone the revision of ripe-128 and ripe-129 until after January. Updated documents will then be sent out. The documents can be found at ftp://ftp.ripe.net/ripe/docs/ripe-128.{txt,ps} ftp://ftp.ripe.net/ripe/docs/ripe-129.txt or ftp://ftp.ripe.net/ripe/forms/netnum-support.{txt,ps} ftp://ftp.ripe.net/ripe/forms/netnum-application.txt If you have any questions, please don't hesitate to contact us. Kind Regards, Mirjam Kuehne RIPE NCC From igalson at cst.tpsa.pl Thu Nov 2 16:32:36 1995 From: igalson at cst.tpsa.pl (Jacek Igalson) Date: Thu, 2 Nov 1995 16:32:36 +0100 Subject: No subject Message-ID: <199511021532.QAA00796@netio> help From training at ripe.net Thu Nov 9 14:09:03 1995 From: training at ripe.net (RIPE NCC Training) Date: Thu, 09 Nov 1995 14:09:03 +0100 Subject: Registration for Training Course in London closed Message-ID: <9511091309.AA29695@ncc.ripe.net> Dear Local IR's, Local IR Training Course November 27th Wimbledon, London, UK The registration for this Local IR Training course has now been closed. The course is oversubscribed, so we are, regrettably, not able to accept more attendees. There are still places for the course in Oslo, next Monday, 13th November 1995. If you are interested in hosting a course for local IR's, we would be happy to do this. To discuss this further, please send mail to . Kind regards, RIPE NCC Training Team From Daniel.Karrenberg at ripe.net Tue Nov 14 14:51:51 1995 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Tue, 14 Nov 1995 14:51:51 +0100 Subject: pro/cons of virtual hosting services In-Reply-To: Your message of Mon, 13 Nov 1995 11:48:40 MET. <199511131048.LAA20128@nic.inbe.net> References: <199511131048.LAA20128@nic.inbe.net> Message-ID: <9511141351.AA11520@ncc.ripe.net> Dear colleagues, The following questions raises a current problem. Please take note. > luc at 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 From poole at eunet.ch Tue Nov 14 16:05:19 1995 From: poole at eunet.ch (poole at eunet.ch) Date: Tue, 14 Nov 1995 16:05:19 +0100 (MET) Subject: pro/cons of virtual hosting services In-Reply-To: <9511141351.AA11520@ncc.ripe.net> from "Daniel Karrenberg" at Nov 14, 95 02:51:51 pm Message-ID: <199511141505.QAA27883@eunet.ch> > > > Dear colleagues, > > The following questions raises a current problem. Please take note. > ... > 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. Simon From hsu at clinet.fi Tue Nov 14 16:57:15 1995 From: hsu at clinet.fi (Heikki Suonsivu) Date: Tue, 14 Nov 1995 17:57:15 +0200 Subject: pro/cons of virtual hosting services In-Reply-To: <9511141351.AA11520@ncc.ripe.net> References: <199511131048.LAA20128@nic.inbe.net> <9511141351.AA11520@ncc.ripe.net> Message-ID: <199511141557.RAA25300@katiska.clinet.fi> Daniel Karrenberg writes: > 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. This means that - people can't start with a WWW hotel and then move the server to their own host after they have been connected, without trouble of readvertising their WWW page. Lots of people start this way, as visibility in WWW is important, but they don't know enough of Internet to take it in their everyday business, and are afraid of security issues involved here. But usually they will move it, sooner or later. - it is annoying to search for someone's page if one has to know who is the WWW provider first. - most companies seem very reluctant to allow service provider name to be visible in their name, both for image reasons and the simple fact that it gives too much control to service provider: The company can't simply switch the service provider if they aren't pleased with the one they have been using. It seems to me to be an overkill to save single IP numbers, in particular when they are only consumed one per company? -- Heikki Suonsivu, T{ysikuu 10 C 83/02210 Espoo/FINLAND, hsu at clinet.fi work +358-0-4375209 fax -4555276 home -8031121 From Daniel.Karrenberg at ripe.net Tue Nov 14 17:08:12 1995 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Tue, 14 Nov 1995 17:08:12 +0100 Subject: pro/cons of virtual hosting services In-Reply-To: Your message of Tue, 14 Nov 1995 17:57:15 +0200. <199511141557.RAA25300@katiska.clinet.fi> References: <199511141557.RAA25300@katiska.clinet.fi> Message-ID: <9511141608.AA13930@ncc.ripe.net> > Heikki Suonsivu writes: > > Daniel Karrenberg writes: > > 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. > > This means that > > - people can't start with a WWW hotel and then move the server to their own > host after they have been connected, without trouble of readvertising their > WWW page. Lots of people start this way, as visibility in WWW is > important, but they don't know enough of Internet to take it in their > everyday business, and are afraid of security issues involved here. But > usually they will move it, sooner or later. > > - it is annoying to search for someone's page if one has to know who is the > WWW provider first. > > - most companies seem very reluctant to allow service provider name to be > visible in their name, both for image reasons and the simple fact that it > gives too much control to service provider: The company can't simply switch > the service provider if they aren't pleased with the one they have been > using. All this is addressed in the second soloution above, isn't it. > It seems to me to be an overkill to save single IP numbers, in particular > when they are only consumed one per company? Unfortunately it is not overkill. We have seen requests for cosiderable amounts of address space for these purposes. The soloution proposed works without any additional address space and has the only drawback that the company name has to appear twice in the URL and not even that if you just choose unique names for the first part of the URL. Daniel From Daniel.Karrenberg at ripe.net Tue Nov 14 17:17:14 1995 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Tue, 14 Nov 1995 17:17:14 +0100 Subject: pro/cons of virtual hosting services In-Reply-To: Your message of Tue, 14 Nov 1995 16:05:19 MET. <199511141505.QAA27883@eunet.ch> References: <199511141505.QAA27883@eunet.ch> Message-ID: <9511141617.AA14052@ncc.ripe.net> > poole at 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? Daniel From GeertJan.deGroot at ripe.net Tue Nov 14 17:34:55 1995 From: GeertJan.deGroot at ripe.net (Geert Jan de Groot) Date: Tue, 14 Nov 1995 17:34:55 +0100 Subject: pro/cons of virtual hosting services In-Reply-To: Your message of "Tue, 14 Nov 1995 17:08:12 +0100." <9511141608.AA13930@ncc.ripe.net> Message-ID: <9511141634.AA14369@ncc.ripe.net> On Tue, 14 Nov 1995 17:08:12 +0100 Daniel Karrenberg wrote: > The soloution proposed works without any additional address space and > has the only drawback that the company name has to appear twice in the > URL and not even that if you just choose unique names for the first part > of the URL. As far as I understand (I have not checked the latest specs), even that problem would be solved with the new version of HTML. The change is that the full URL would be sent of the server (i.e. www://www.ripe.net/index.html instead of just index.html), and the domain name can be derived that way. Geert Jan From poole at eunet.ch Tue Nov 14 18:10:16 1995 From: poole at eunet.ch (poole at eunet.ch) Date: Tue, 14 Nov 1995 18:10:16 +0100 (MET) Subject: pro/cons of virtual hosting services In-Reply-To: <9511141617.AA14052@ncc.ripe.net> from "Daniel Karrenberg" at Nov 14, 95 05:17:14 pm Message-ID: <199511141710.SAA28271@eunet.ch> > > 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? Because the customer wants something else (and they pay your wage too in the end). Please realize that we are talking about a purely -superficial- difference of ~$3000* for running a seperate server (PC based) vs. a virtual one (typical production costs for a commercial WWW server are multiple 10'000 of dollars, so we are really talking about noise). Neither solution conserves address space, but at least the virtual server conserves certain other (more important?) resources *. 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. Simon From Daniel.Karrenberg at ripe.net Tue Nov 14 18:13:57 1995 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Tue, 14 Nov 1995 18:13:57 +0100 Subject: pro/cons of virtual hosting services In-Reply-To: Your message of Tue, 14 Nov 1995 18:10:16 MET. <199511141710.SAA28271@eunet.ch> References: <199511141710.SAA28271@eunet.ch> Message-ID: <9511141713.AA14921@ncc.ripe.net> > poole at eunet.ch writes: > > > > 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? > > Because the customer wants something else (and they pay your wage too > in the end). I contest that the majority wants something different from my second soloution. Please re-read it. > Please realize that we are talking about a purely -superficial- difference > of ~$3000* for running a seperate server (PC based) vs. a virtual one > (typical production costs for a commercial WWW server are multiple 10'000 > of dollars, so we are really talking about noise). Neither solution > conserves address space, but at least the virtual server conserves certain > other (more important?) resources *. But you can run a virtual server without wasting address space! > 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. Daniel From poole at eunet.ch Tue Nov 14 18:25:34 1995 From: poole at eunet.ch (poole at eunet.ch) Date: Tue, 14 Nov 1995 18:25:34 +0100 (MET) Subject: pro/cons of virtual hosting services In-Reply-To: <9511141713.AA14921@ncc.ripe.net> from "Daniel Karrenberg" at Nov 14, 95 06:13:57 pm Message-ID: <199511141725.SAA28311@eunet.ch> > > > > poole at eunet.ch writes: > > > > > > 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? > > > > Because the customer wants something else (and they pay your wage too > > in the end). > > I contest that the majority wants something different from my > second soloution. Please re-read it. Some do, some don't (up to now we have provided exactlly your solution, and some customers are completly content with it, others aren't). .... > But you can run a virtual server without wasting address space! > > > 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. 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. Simon From bilse at EU.net Tue Nov 14 19:36:08 1995 From: bilse at EU.net (Per Gregers Bilse) Date: Tue, 14 Nov 1995 19:36:08 +0100 Subject: pro/cons of virtual hosting services In-Reply-To: <9511141713.AA14921@ncc.ripe.net> Message-ID: <199511141836.AA12838@jotun.EU.net> This really is a non-issue. Apart from customer expectations, the addresses typically come from under-populated C LANs anyway. Increasing utilisation of those LANs would mean subnetting, which in itself would send large amounts of space out the window. And if one forces customers to get their own machine to get their own address, it will have to go on a separate ethernet segment (security, ethernet eavesdropping). This means even more and worse subneting. Apart from that, I don't expect virtual servers ever to be an even measurable part of address space consumption. Customers who are savvy enough to ask for it are likely in short order to migrate to a separate server and soon thereafter to an Internet connection for the whole company. That obviously doesn't mean it should be encouraged and I believe most people are (or at least should be) gently discouraging it, by charging more for it. But hammering on this issue as something terribly wasteful is way off track. Worry about AS number depletion, route flaps, and junk routes and what not from wannabe ISPs instead -- these things will bring the Internet to its knees long before we run out of address space. By way of example, yesterday somebody was announcing net 0; I sent a note to their upstream provider, who Cc'ed me on the note they sent downstream. The note reads: > To: XXXXXXXX > Subject: Announcing default > Cc: bilse at EU.net, noc at UPSTREAM-PROVIDER.NET > > XXXXXXXXXX, please handle this as soon as possible. > There is some bgp config setting that says "advertise the default" > and you need to turn that off. "The blue button, the blue button." -- ====== ___ === Per G. Bilse, Mgr Network Operations Ctr ===== / / / __ ___ _/_ ==== EUnet Communications Services B.V. ==== /--- / / / / /__/ / ===== Singel 540, 1017 AZ Amsterdam, NL === /___ /__/ / / /__ / ====== tel: +31 20 6233803, fax: +31 20 6224657 === ======= 24hr emergency number: +31 20 421 0865 === Connecting Europe since 1982 === http://www.EU.net; e-mail: bilse at EU.net From bilse at EU.net Tue Nov 14 19:45:56 1995 From: bilse at EU.net (Per Gregers Bilse) Date: Tue, 14 Nov 1995 19:45:56 +0100 Subject: pro/cons of virtual hosting services In-Reply-To: <199511141836.AA12838@jotun.EU.net> Message-ID: <199511141845.AA12874@jotun.EU.net> On Nov 14, 19:36, Per Gregers Bilse wrote: > run out of address space. By way of example, yesterday somebody was > announcing net 0; I sent a note to their upstream provider, who Cc'ed Ohh ... before anybody starts: no, we have been running with full routing since some time around December 1993 / January 1994. -- ====== ___ === Per G. Bilse, Mgr Network Operations Ctr ===== / / / __ ___ _/_ ==== EUnet Communications Services B.V. ==== /--- / / / / /__/ / ===== Singel 540, 1017 AZ Amsterdam, NL === /___ /__/ / / /__ / ====== tel: +31 20 6233803, fax: +31 20 6224657 === ======= 24hr emergency number: +31 20 421 0865 === Connecting Europe since 1982 === http://www.EU.net; e-mail: bilse at EU.net From jcaron at pressimage.net Tue Nov 14 19:55:16 1995 From: jcaron at pressimage.net (Jacques Caron) Date: Tue, 14 Nov 1995 19:55:16 +0100 Subject: pro/cons of virtual hosting services Message-ID: At 17:17 14/11/95, Daniel Karrenberg wrote: > > poole at 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 at 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 From cor at xs4all.net Tue Nov 14 20:00:09 1995 From: cor at xs4all.net (Cor Bosman) Date: Tue, 14 Nov 1995 20:00:09 +0100 (MET) Subject: pro/cons of virtual hosting services In-Reply-To: <9511141617.AA14052@ncc.ripe.net> from "Daniel Karrenberg" at Nov 14, 95 05:17:14 pm Message-ID: <199511141900.AA05617@xs1.xs4all.nl> > > poole at 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 What is significant? > 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. We offer the www.customer.nl method with virtual hosts. 1 ip adress per company, and they ofcourse need to show chamber of commerce papers first as per dutch domain rules. I really don't see the harm in this. > 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? Well, the 'significant additional functionality' is your opinion. Customers seem to think otherwise, and an ISP has to contiuously make decisions balancing both RIPE's needs as the customers needs. And not always does the balance work in RIPE's favour (most of the time it does :). Although im totally in favour of trying to preserve ip space, in this case I really believe it is not as significant as it is portrayed to be. Not as long as it stays within 1 or 2 Class C nets. Cor ------------------------------------------------------------------------------ | Cor Bosman | ____Xs4all Public Access____ | tel: +31-(0)20-622-2885 | | cor at xs4all.net | Network Administrator | fax: +31-(0)20-622-2753 | ------------------The net routes around censorship---------------------SP5---- From jcaron at pressimage.net Tue Nov 14 20:11:25 1995 From: jcaron at pressimage.net (Jacques Caron) Date: Tue, 14 Nov 1995 20:11:25 +0100 Subject: pro/cons of virtual hosting services Message-ID: At 18:25 14/11/95, poole at 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 at 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 From oliver at demon.net Tue Nov 14 23:31:28 1995 From: oliver at demon.net (Oliver Smith) Date: Tue, 14 Nov 1995 22:31:28 +0000 (GMT) Subject: pro/cons of virtual hosting services In-Reply-To: <9511141713.AA14921@ncc.ripe.net> from "Daniel Karrenberg" at Nov 14, 95 06:13:57 pm Message-ID: <9511142231.aa15346@office.demon.net> /> > Because the customer wants something else (and they pay your wage too /> > in the end). /> /> I contest that the majority wants something different from my /> second soloution. Please re-read it. Technically, you may be right; however, as we in the UK have experienced with Domain Registrations, a lot of miseducation is floating around so that many companies are now selling URLs - that's the bit that most of us call a host name. The UK domain-registration rules have been relaxed, and fierce debate continues about this, so that these people can turn the DNS into DURLS. And the world becomes full of one-page web """sites""" (pet hate, can you tell? :-) Oliver -- Duty Hostmaster, Corporate Division, Demon Internet. 322 Regents Park Road, Finchley, London N3 3RD, England (0181-371-1000) Singel 540, 1017 AZ, Amsterdam, Netherlands (020-4222-000) From oliver at demon.net Tue Nov 14 23:05:49 1995 From: oliver at demon.net (Oliver Smith) Date: Tue, 14 Nov 1995 22:05:49 +0000 (GMT) Subject: pro/cons of virtual hosting services In-Reply-To: <199511141557.RAA25300@katiska.clinet.fi> from "Heikki Suonsivu" at Nov 14, 95 05:57:15 pm Message-ID: <9511142232.aa15432@office.demon.net> In a previous message Heikki Suonsivu wrote: /> - most companies seem very reluctant to allow service provider name to be /> visible in their name, both for image reasons and the simple fact that it /> gives too much control to service provider: The company can't simply switch /> the service provider if they aren't pleased with the one they have been /> using. /> /> It seems to me to be an overkill to save single IP numbers, in particular /> when they are only consumed one per company? There are other reasons why people choose this option, which shouldn't be overlooked. 1. Leased Line customers who simply don't have enough bandwidth to run their big & popular web server over. They don't, however, want to resort to a tacky URL again - they want a host on the providers network. Most easily achieved using a virtual host. 2. Companies who don't, as yet, have a leased line, but may have a significant web *site* (I'm personally annoyed at the number of one-page "web sites" that are nothing more than a waste of DNS and doomed to a short life). They want, again, a machine on your network, and a virtual host is the easiest way of doing this. In both these cases, that IP address only replaces a real machine. I would quite like to see some documentation of "valid uses of an IP address", especially if providing a web service is not considered to be such [no, you don't see my personal opinion there, you see my curiosity]. Why does a network of 60 PC's (which do nothing other than browse web and communicate with the local smart host) warrant a /24 or /25, when by using SOCKs, to get dynamic addressing for the network, and a web proxy, you could use a /30 or /29. If they were dialup hosts, they would be told that using static IP is wrong. Maybe if the RIPE community could produce a public-domain and reliable SOCKs based platform, we could reclaim large numbers of /24's and bigger which are currently only used by "browsers" and have no real excuse not to be in 1597 space. This can only be fair if RIPE are going to question the validity of the use of an IP address... Oliver From steiff at NetVision.net.il Wed Nov 15 14:35:20 1995 From: steiff at NetVision.net.il (Shahar Steiff) Date: Wed, 15 Nov 1995 07:35:20 -0600 (CST) Subject: pro/cons of virtual hosting services In-Reply-To: <9511141617.AA14052@ncc.ripe.net> Message-ID: On Tue, 14 Nov 1995, Daniel Karrenberg wrote: > 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? "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. Sincerely, Shahar Steiff WAN MAN crew - NetVision - Commercial Israeli Internet Provider --------------------------------------------- E-mail: steiff at NetVision.net.il Personal address info at NetVision.net.il for information. support at NetVision.net.il for technical support. Gopher: gopher.NetVision.net.il www: http://www.NetVision.net.il/ Phone: +972-4-8550-330 Fax: +972-4-8550-345 NetVision - The best Internet Service Provider in the world... (and one of the best in Israel !) From 116780 at ibmmail.com Wed Nov 15 10:01:44 1995 From: 116780 at ibmmail.com (116780 at ibmmail.com) Date: Wed, 15 Nov 1995 04:01:44 EST Subject: PRO/CONS OF VIRTUAL HOSTING SERVICES Message-ID: <9511150902.AA22284@ncc.ripe.net> >"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 From peter at demon.net Wed Nov 15 10:20:24 1995 From: peter at demon.net (Peter Galbavy) Date: Wed, 15 Nov 1995 09:20:24 +0000 (GMT) Subject: pro/cons of virtual hosting services In-Reply-To: <199511141900.AA05617@xs1.xs4all.nl> from "Cor Bosman" at Nov 14, 95 08:00:09 pm Message-ID: <9511150920.aa12856@office.demon.net> > Well, the 'significant additional functionality' is your opinion. > Customers seem to think otherwise, and an ISP has to contiuously make > decisions balancing both RIPE's needs as the customers needs. > And not always does the balance work in RIPE's favour (most of the time > it does :). Although im totally in favour of trying to preserve ip > space, in this case I really believe it is not as significant as it > is portrayed to be. Not as long as it stays within 1 or 2 Class C nets. I would put it even more stongly. RIPE is there to do a jobs, which is being a registry. Please will a RIPE rep. show me where it says that they have legal and/or moral responsibility to dictate how a company does business ? These virtual web sites are one IP address per company. Should we be asking the RIPE to give a class C to each of these comanies and then use one for the WWW server ? This is as an alternative to allowing companies that sell the virtual space to using their address space much more efficiently. Regards, -- Peter Galbavy peter at 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/ From peter at demon.net Wed Nov 15 10:28:12 1995 From: peter at demon.net (Peter Galbavy) Date: Wed, 15 Nov 1995 09:28:12 +0000 (GMT) Subject: pro/cons of virtual hosting services In-Reply-To: <9511141713.AA14921@ncc.ripe.net> from "Daniel Karrenberg" at Nov 14, 95 06:13:57 pm Message-ID: <9511150928.aa16380@office.demon.net> > I contest that the majority wants something different from my > second soloution. Please re-read it. I disagree. Most *paying customers* want http://www.xxx.com/ and will expect to get it. These people are only buying service on our site because it make better sense, not because most of them could not afford a leased line *and* take a whole calss C or more with them. > But you can run a virtual server without wasting address space! Not at the moment. > > 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. Isn't. Daniel, Please keep away from trying to develop business models for the 'net. That is the jobs of the companies that pay your wages. You are not there to decide how applications will work today. Feel free to sit on working groups and influence future developments, which will make the 'net a better place, but please do not try to change the way non-RIPE organisations are already working. Regards, -- Peter Galbavy peter at 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/ From woeber at cc.univie.ac.at Wed Nov 15 11:00:04 1995 From: woeber at cc.univie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Wed, 15 Nov 1995 11:00:04 MET Subject: Routing wars pending? Message-ID: <009996D1.FB926CDA.1@cc.univie.ac.at> 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 at 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 -------------------------------------------------------------------------- From HANK at VM.TAU.AC.IL Wed Nov 15 14:11:41 1995 From: HANK at VM.TAU.AC.IL (Hank Nussbacher) Date: Wed, 15 Nov 95 14:11:41 IST Subject: Routing wars pending? In-Reply-To: Message of Wed, 15 Nov 1995 11:00:04 MET from Message-ID: <9511151234.AA25169@ncc.ripe.net> 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 at 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 From Daniel.Karrenberg at ripe.net Wed Nov 15 14:59:48 1995 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Wed, 15 Nov 1995 14:59:48 +0100 Subject: pro/cons of virtual hosting services In-Reply-To: Your message of Wed, 15 Nov 1995 09:28:12 GMT. <9511150928.aa16380@office.demon.net> References: <9511150928.aa16380@office.demon.net> Message-ID: <9511151359.AA26213@ncc.ripe.net> > Peter Galbavy writes: > I would put it even more stongly. RIPE is there to do a jobs, which is > being a registry. Please will a RIPE rep. show me where it says that > they have legal and/or moral responsibility to dictate how a company > does business ? > ... > Please keep away from trying to develop business models for the 'net. That > is the jobs of the companies that pay your wages. You are not there to > decide how applications will work today. Feel free to sit on working > groups and influence future developments, which will make the 'net a > better place, but please do not try to change the way non-RIPE > organisations are already working. Peter, we are not dictating how you do business and certainly the RIPE NCC is not developing business models for the net. We are indeed providing registration services among other things. The IPv4 address space is a very limited resource and consequently address space conservation is part of the policies we have to implement when acting as a European Regional Internet Registry. The global policies are set by IANA and the local European variations thereof in the RIPE local-IR working group, i.e. this forum. Implementing conservation policies is the single item which gives the NCC the most grief and the most work. But someone has to do this in the interest of the Internet as a whole and if we would not do it it would be bad for the industry. We would very much like to be spared public abuse of the kind we experience from time to time when we question practises which are inherently wasteful of address space for little or no good reason. Please imagine where Internet routing would be now if we would have continued to assign /16s (Bs) to anyone with more than 254 hosts on a physical subnet or if noone would have pushed for a registry system that is independent and yet responsive to provider needs, sustains itself and allows for routing aggregation. Daniel From Daniel.Karrenberg at ripe.net Wed Nov 15 15:38:11 1995 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Wed, 15 Nov 1995 15:38:11 +0100 Subject: pro/cons of virtual hosting services In-Reply-To: Your message of Tue, 14 Nov 1995 19:55:16 MET. References: Message-ID: <9511151438.AA26837@ncc.ripe.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 From hostmaster at sztaki.hu Wed Nov 15 18:12:46 1995 From: hostmaster at sztaki.hu (Domain registration staff) Date: Wed, 15 Nov 1995 18:12:46 +0100 (MET) Subject: An idea about virtual hosting services In-Reply-To: <9511151359.AA26213@ncc.ripe.net> Message-ID: Dear All, I have an idea about virtual servers. There should be a new DNS resource record, containing additional port or URL information. Or this info may be recorded in TXT records: E.g. www.company1.xx. CNAME www.provider.xx. TXT "HTTP-PORT:881" www.company2.xx. CNAME www.provider.xx. TXT "HTTP-PORT:882" or www.company1.xx. CNAME www.provider.xx. TXT "HTTP-PATH:/company1" www.company2.xx. CNAME www.provider.xx. TXT "HTTP-PATH:/company2" or even without TXT, using just some special hostnames www.company1.xx. CNAME http-port-881.www.provider.xx. http-port-881.www.provider.xx. CNAME www.provider.xx. www.company2.xx. CNAME http-port-882.www.provider.xx. http-port-882.www.provider.xx. CNAME www.provider.xx. (OK, I know www.company1.xx may not have CNAME and TXT at the same time. This is just a demonstration.) Then webmaster at www.provider.xx should set up a document hierarchy as usual: http://www.provider.xx/company1/intro.html http://www.provider.xx/company2/intro.html and/or run differend http servers on different ports. A slighly enhanced browser would realize the additional information from DNS and changes the user given URL http://www.company1.xx to http://www.provider.xx:881 or http://www.provider.xx/company1. Unmodified browsers can reach the docs as do now. Sorry if I was too boring. ;-) Gabor ---------------------------------------------------------------------- Gabor Kiss Computer and Automation Institute of the Hungarian Academy of Sciences H-1132 Budapest, Victor Hugo str. 18-22, Hungary E-mail: postmaster at sztaki.hu; Tel: +36 1 149 7986; Fax: +36 1 129 7866 From aid at u-net.net Wed Nov 15 19:47:33 1995 From: aid at u-net.net (Adrian Bool) Date: Wed, 15 Nov 1995 18:47:33 -0000 Subject: pro/cons of virtual hosting services In-Reply-To: <9511151438.AA26837@ncc.ripe.net> Message-ID: > 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/ From liman at sunet.se Wed Nov 15 23:20:11 1995 From: liman at sunet.se (Lars-Johan Liman) Date: Wed, 15 Nov 1995 23:20:11 +0100 Subject: An idea about virtual hosting services In-Reply-To: Your message of "Wed, 15 Nov 1995 18:12:46 +0100." Message-ID: <199511152220.XAA01364@fliptop.pilsnet.sunet.se> > Dear All, > I have an idea about virtual servers. > There should be a new DNS resource record, containing additional > port or URL information. Or this info may be recorded in TXT records: There is already work going on in that very direction by the people that work with URLs, URNs and the like in IETF circles. The lines they are working along are in line with what you suggest, but more integrated to other infrastructures, like Object Identifiers and the like. If you want more information, send me a note, and I'll see if I can dig out some refences. Best regards, /Liman #------------------------------------------------------------------------- # Lars-Johan Liman ! Internet: liman at sunet.se # Ebone/NORDUnet/SUNET Operations Centre ! BITNET : LIMAN at SEARN # Royal Institute of Technology, Sweden ! HTTP : //www.sunet.se/~liman # ! Voice : Int +46 8 - 790 65 60 #------------------------------------------------------------------------- From Daniel.Karrenberg at ripe.net Thu Nov 16 14:30:04 1995 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Thu, 16 Nov 1995 14:30:04 +0100 Subject: Routing wars pending? In-Reply-To: Your message of Wed, 15 Nov 1995 14:11:41 +0700. <9511151234.AA25169@ncc.ripe.net> References: <9511151234.AA25169@ncc.ripe.net> Message-ID: <9511161330.AA13641@ncc.ripe.net> > Hank Nussbacher writes: > 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? This is policy for address space allocated/assigned via the RIPE NCC. If a local registry does it they remain responsible for the assignments. They will also have problesm with future allocations unless the all the sub-allocated space runs out at the same time. > Yes Europe is very organized - but what do you do about the USA? Fix it. :-) Daniel From 116780 at ibmmail.com Thu Nov 16 10:01:20 1995 From: 116780 at ibmmail.com (116780 at ibmmail.com) Date: Thu, 16 Nov 1995 04:01:20 EST Subject: PRO/CONS OF VIRTUAL HOSTING SERVICES Message-ID: <9511161705.AA17226@ncc.ripe.net> 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 From oliver at demon.net Fri Nov 17 17:48:12 1995 From: oliver at demon.net (Oliver Smith) Date: Fri, 17 Nov 1995 16:48:12 +0000 (GMT) Subject: Valid Use [was pro/cons of virtual hosting] Message-ID: <9511171648.aa01817@office.demon.net> 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 From dguthrie at technocom.co.uk Sat Nov 18 15:09:00 1995 From: dguthrie at technocom.co.uk (David Guthrie) Date: Sat, 18 Nov 95 11:09:00 -0300 Subject: Virtual Web Hosting Services Message-ID: <50C9822F01450200@c2gate2.technocom.co.uk> 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. From schoultz at sunet.se Sat Nov 18 14:47:52 1995 From: schoultz at sunet.se (Rickard Schoultz) Date: Sat, 18 Nov 1995 14:47:52 +0100 (MET) Subject: Virtual Web Hosting Services In-Reply-To: <50C9822F01450200@c2gate2.technocom.co.uk> Message-ID: Another aspect of virtual servers is that people who actually has tried implementing Daniel's second method (which was a CNAME from www.company.com to www.provider.com and referring to the page as http://www.company.com/company/) discovers that the most popular web browsers makes a dns lookup followed by a reverse lookup of the URL they are looking at and presents this information at the top of the page. This means that a reference to http://www.company.com/company/ will show up as http://www.provider.com/company/ on the user's screen. I can understand that from a marketing point, this is not a good thing. There has been endless discussions about this on the web developers lists, but I think this has been resolved by proposing a new HTTP header "Host:" instead of passing the full URL, since this would break older implementations of HTTP servers (~40000 installed). -Rickard -- Rickard Schoultz SUNET/NORDUnet/Ebone Operations Center KTH, S-100 44 Stockholm, Sweden Phone: +46-8-7908365 Fax: +46-8-241179 From robert at DK.net Sun Nov 19 15:47:49 1995 From: robert at DK.net (Robert Martin-Legene) Date: Sun, 19 Nov 1995 15:47:49 +0100 (MET) Subject: Virtual Web Hosting Services In-Reply-To: Message-ID: On Sat, 18 Nov 1995, Rickard Schoultz wrote: > discovers that the most popular web browsers makes a dns lookup followed > by a reverse lookup of the URL they are looking at and presents this > information at the top of the page. This means that a reference to > http://www.company.com/company/ will show up as > http://www.provider.com/company/ on the user's screen. I don't think the client does a reverse lookup. But in the configuration of your httpd, you tell it what it's hostname is. When people make a wrong reference that requires a redirect, the server sends the configured name as part of the new URL. In general people have a tendensy of forgetting the trailing slash on URL's when it's a directory. This makes the client establish an extra TCP connection - the first one only to get a redirect. For example http://www.DK.net/nic would make the server redirect the client to http://www.DK.net/nic/ making it connect twice to get the wanted URL. I believe that's what you're seing. I do not see a problem with allocating an IP# for an extra pseudo-interface on a computer as the complete URL isn't transfered today. If we are not allowed to do it, people will get C's to do the same (in the name of the organisation wanting the service), which is much more expensive. -- Robert Martin-Leg?ne, = EUnet Denmark = DKnet, Fruebjergvej 3, DK-2100 Kobenhavn O, +45 39 17 99 00 From training at ripe.net Mon Nov 20 12:19:01 1995 From: training at ripe.net (RIPE NCC Training) Date: Mon, 20 Nov 1995 12:19:01 +0100 Subject: Announcement for Local IR Training Course in Amsterdam Message-ID: <9511201119.AA10108@ncc.ripe.net> * * * Announcement * * * Local Internet Registries Training Course Date: Thursday, 1. February, 1996 Time: 0900 - 1700 Venue: RIPE NCC Kruislaan 409 1098 SJ Amsterdam The Netherlands -------------- next part -------------- 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 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 ;-). -------------- next part -------------- %%%%%%%%%%% 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 . 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 . 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.) # REG [ ] 3) Your e-mail address # EMAIL [ ] 4) The course you plan to attend (date and location) # COURSE [ ] %END From oliver at demon.net Thu Nov 23 12:44:44 1995 From: oliver at demon.net (Oliver Smith) Date: Thu, 23 Nov 1995 11:44:44 GMT Subject: pro/cons of virtual hosting services In-Reply-To: <9511151438.AA26837@ncc.ripe.net> References: <9511151438.AA26837@ncc.ripe.net> Message-ID: <30b44fb3.514411945@post.demon.nl> 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 /* work://mail/oliver at demon.net require 'TeaWhiteOne.regularly'; # */ home://mail/oliver at kfs.org From peter at demon.net Mon Nov 27 10:07:25 1995 From: peter at demon.net (Peter Galbavy) Date: Mon, 27 Nov 1995 09:07:25 +0000 (GMT) Subject: pro/cons of virtual hosting services In-Reply-To: <30b44fb3.514411945@post.demon.nl> from "Oliver Smith" at Nov 23, 95 11:44:44 am Message-ID: <9511270907.aa20986@office.demon.net> > 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 at 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/ From Ndeh_Ningo at camfido.gn.apc.org Mon Nov 27 15:45:07 1995 From: Ndeh_Ningo at camfido.gn.apc.org (Ndeh_Ningo at camfido.gn.apc.org) Date: Mon, 27 Nov 95 14:45:07 +0000 Subject: keeping in touch Message-ID: <30b9cf2c@p21.f1.n7751.z5.gnfido.fidonet.org> DJR> Hi Ndeh (may I call you so?), Yes. DJR> Do you need an RFC Index (you could look into and tell me DJR> what papers are of interest)? Yes I am going to subscribe to the ripe-list as you recommended. I am currently reading the material you sent. It is a bit confusing for the uninitiated. I shall get in touch when I can pose some specific questions. In the meantime, if you come across anything that you think can be of interest to me, please I'll appreciate receiving it by e-mail. Best regardss Ndeh From arjan at NL.net Tue Nov 28 10:53:00 1995 From: arjan at NL.net (Arjan van de Ven) Date: Tue, 28 Nov 95 10:53 MET Subject: test pls ignore Message-ID: pls ignore From HANK at VM.TAU.AC.IL Tue Nov 28 13:26:59 1995 From: HANK at VM.TAU.AC.IL (Hank Nussbacher) Date: Tue, 28 Nov 95 13:26:59 IST Subject: CIDR FAQ Message-ID: <9511281128.AA04030@ncc.ripe.net> ------------------------------------------------------------------------ The CIDR FAQ Version 5 15 November 1995 ------------------------------------------------------------------------ The following document is a collection of Frequently Asked Questions about CIDR. This document is not meant to be a networking/routing guide and tutorial. Where appropriate pointers to other documents of a more general nature have been mentioned. Updates from a previous version are marked with a '|' in column 1. If you have any questions you would like added, please send them to the editor mentioned below: Hank Nussbacher (Tel Aviv University and IBM Israel) hank at vm.tau.ac.il or hank at ibm.net.il If you would like to "discuss" items from this FAQ please send your mail to cidrd at iepg.org This FAQ is being distributed to the following groups and lists: alt.internet.services alt.internet.access.wanted nanog at merit.edu inet-access at earth.com iap at vma.cc.nd.edu local-ir at ripe.net cidrd at iepg.org |local-ir at apnic.net To retrieve the most up-to-date version of this document: |- ftp://ftp.ibm.net.il/pub/docs/cidr.faq |- http://www.rain.net/faq/cidr.faq.html ------------------------------------------------------------------------ General questions ----------------- 1. What does CIDR stand for? CIDR stands for Classless Inter-Domain Routing and is documented in RFC1517/1518/1519/1520. CIDR is an effective method to stem the tide of IP address allocation as well as routing table overflow. Without CIDR having been implemented in 1994 & 1995, the Internet would not be functioning today. Basically, CIDR eliminates the concept of class A, B, and C networks and replaces this with a generalized "IP prefix". CIDR can be used to perform route aggregation in which a single route can cover the address space of several "old-style" network numbers and thus replace a lot of old routes. This lessens the local administrative burden of updating external routing, saves routing table space in all backbone routers and reduces route flapping (rapid changes in routes), and thus CPU load, in all backbone routers. CIDR will also allow delegation of pieces of what use d to be called "network numbers" to customers, and therefore make it possible to utilize the available address space more efficiently. See question #6 below for details on "IP prefix"s. 2. What is an ASN? ASN stands for Autonomous System Number and acts to merge many networks into a logical domain. 3. What is BGP? BGP stands for Border Gateway Protocol and is the de-facto standard for routing between Autonomous Systems in the Internet. All communications between Internet Service Providers (ISP) is handled via BGP4 which supports CIDR. 4. Why should I make the effort and convert my routing to be CIDRized? The routing tables in the Internet have been growing as fast as the Internet and the router technology specifically and computer technology in general has not been able to keep pace. In December 1990 there were 2190 routes and 2 years later there were over 8500 routes. In July 1995 there are now over 29,000 routes, which require approximately 10 MB in a router with a single peer. Routers at interconnection points (or multi-homed hosts doing full routing with many peers) receive these routes from several peers, and need several dozen megabytes of RAM (and the appropriate CPU horsepower) to handle this. A list of those routers that can handle this appears at the end of this question. Routers with 64MB of memory have the capacity for approximately 60,000 routes after which some routes will just have to be left out of the global routing tables, and the more likely ones to be left out are routes covering small pieces of address space. Without the CIDRization work that has gone on for the past 2 years the routing tables would be in excess of 65,000 routes. By CIDRizing you help the Internet reduce the routing overload as well as increasing the liklihood that in the future your routes will be carried by all ISPs. The major benefit of CIDR is to allow for continuous, uninterrupted growth of the Internet. For a significant percentage of sites connected to the Internet the value of the Internet increases with the total number of sites connected to the Internet. Therefore, taking steps needed to allow for continuous uninterrupted growth (like CIDRizing, or renumbering) is beneficial to such sites. The routers today that are available to handle the full routing table are: cisco 7000 w/ 64Mb cisco 4500 w/ 32Mb IBM ENSS and CNSS w/ 64Mb BayNetworks models AN/ASN/BLN/BCN w/ 32Mb 5. Can you give an example of a simple CIDR configuration for a cisco router? The following example creates 2 aggregates and suppresses any more specific addresses that may be contained within those aggregates. The access-list causes only those nets to be distributed as listed, and not any others that may exist in the BGP routing tables. router bgp 64100 no synchronization aggregate-address 172.16.0.0 255.248.0.0 summary-only aggregate-address 192.168.50.0 255.255.255.0 summary-only neighbor 192.168.54.2 remote-as 65000 neighbor 192.168.54.2 distribute-list 12 out default-metric 70 ! access-list 12 permit 192.168.50.0 0.0.0.255 access-list 12 permit 172.16.0.0 0.7.255.255 | Another method might be: | | router bgp 64100 | no synchronization | aggregate-address 172.16.0.0 255.248.0.0 | aggregate-address 192.168.50.0 255.255.255.0 | neighbor 192.168.54.2 remote-as 65000 | neighbor 192.168.54.2 distribute-list 102 out | default-metric 70 | ! | access-list 102 deny 172.16.0.0 0.7.255.255 255.252.0.0 0.3.255.255 | access-list 102 deny 192.168.50.0 0.0.0.255 255.255.255.128 0.0.0.127 An alternate method is via network and route statements: router bgp 64100 no synchronization network 172.16.0.0 mask 255.248.0.0 network 192.168.50.0 mask 255.255.255.0 neighbor 192.168.54.2 remote-as 65000 neighbor 192.168.54.2 default-metric 70 ip route 172.16.0.0 255.248.0.0 Null0 254 ip route 192.168.50.0 255.255.255.0 Null0 254 In this case, only those routes explicitly mentioned in "network" statements will be announced with BGP. For these routes to be announced, there has to be a corresponding route in the IP forwarding table, thus the need to create the static routes. The static routes will also serve as "pull-ups" for the route advertisements and thus prevent route flapping: these routes will always be announced with BGP by this router. Note that as long as more specific routes exist internally in your network, these will be used in preference to the static "less specific" route entries (longest prefix matching is being used). A good rule to follow is to never redistribute IGP learnt routes directly into BGP, but to rather use network or aggregate-address statements. And if you must redistribute dynamically learnt IGP routes into BGP, you MUST use filtering. The reasons for this advice are several, some of which are: 1) if your IGP is classful (e.g. RIP or IGRP) you will by default not do any route aggregation 2) if you have an internal stability problem (accidents do happen), this will be reflected as a "route flap" in the whole routing system, globally burning CPU cycles better spent on other things 3) if the IGP -> BGP transition is unrestricted, this can lead to false routing information escaping from your network (especially if you do not fully have administrative control over your IGP) 6. What do all these /16s and /24s mean in my BGP tables? This refers to the number of bits of the network part of the IP address. A former class B may appear as 172.50.0.0/16, which is the same as 256 class C's which can appear as 192.200.0.0/16. A single class C appears as 192.201.1.0/24. These "things" are often called an "IP prefix", which consists of an IP address and a mask length. The mask length specifies the number of leftmost contiguous significant bits in the corresponding IP address. Thus, an IP prefix with a prefix length of 15 (denoted /15) covers the address space of 128k IP addresses, and a /17 covers the address space of 32k IP addresses. Here is a table of the more popular CIDR blocks: # of former CIDR class C block nets ---- ---- /27 1/8 /26 1/4 /25 1/2 /24 1 /23 2 /22 4 /21 8 /20 16 /19 32 /18 64 /17 128 /16 256 = 1 former class B /15 512 /14 1024 /13 2048 In general, advertising a prefix covering less address space than a /24 prefix will probably not get into the global routing tables, and global Internet connectivity is less likely to happen. Note that for you as an administrator of an AS, it is a good idea to announce as few prefixes as possible and to utilize the address space as much as possible. | A more comprehensive table came out in October 1995 as: | | RFC1860: Variable Length Subnet Table For IPv4 | | This RFC is being revised and a new one will be out shortly. 7. Do I need to carry the full Internet routing table? When would it be necessary? What routers on the Internet carry full routing tables and how much memory is needed? No you do not need to carry the full Internet routing table. If you are single-homed, meaning you have a single connection to an ISP, then all you need to do is point a default route to the ISP and tell your ISP not to send you the full routing table. If you are multi-homed, you will want to know which nets to route via connection A and which nets to route via connection B. The easiest way to do this is to request a partial routing table from one ISP - with those nets that are closest to them, and default everything else to the other ISP. This way your routing tables need not contain the entire Internet universe but only a small subset. The closer you get to the hub or nexus of the Internet, the larger your routing tables need to be. For example, those connected to public exchange points (like the NAPs, CIX, STIX, LINX, dGIX) in general, carry full routing tables and run without a default route. 8. What is there in the Internet to stop me from making a mistake and announcing via BGP an aggregate that is larger than the nets I am in charge of? In principle there is nothing to stop you. The responsibility falls on both ends of the BGP link - you are responsible to filter what you announce and the receiving end - if it has its act together - filters also what it *thinks* it should be hearing from you so as prevent mistakes on your part. Those sites that do not work with access lists and filters and just readily accept what is sent to them are just waiting for a problem to happen. Filtering can either be done at the IP network level or at the BGP path (BGP orgin AS) level. See question 20 below for details on a tool to assist in filtering. 9. Who has to renumber with CIDR ? Sites that move from one ISP to another, and who had been allocated addresses from their original ISP's CIDR block, in all likelihood will have to return those addresses as part of the move. The reason is to keep the number of prefixes in the global routing system within the limits of current technology. | For further hints and procedures for renumbering, see the PIER | (Procedures for Internet/Enterprise Renumbering) homepage at: | | http://www.isi.edu:80/div7/pier Specific questions ------------------ 10. I have a /16 but have registered parts of it as /24s in the RADB. I now want to CIDRize. The problem is parts of the /16s are missing and are routed via a different ASN. Can you explain how more specific routes override more general ones and will I hurt my routing if I just advertise the /16 and not a bunch of /20s and /21s? There are two aspects to the answer: 1) Real (BGP) world: Given there are several AS's sharing addresses out of a /16 prefix, every AS should advertise exactly those prefixes which it is really originating. However, if there is one AS "originating" a significant majority of this address space, the concerned AS's might agree that this one and only advertises the /16 and all others their more specifics. The more specifics always take precedence over the less specific. 2) Routing registry: The registry DB, of course, should always reflect reality. If in the above example the AS's agree on the "big AS" announcing the /16, the "big AS" should document with the route-object that it's not really originating the whole aggregate by using "hole" attributes (see ripe.181, 5. The Route Object). 11. How can I redistribute our IGP routes (IGRP) so that they become aggregated when sent out via BGP? It is strongly discouraged to redistribute IGPs into BGP, because local IGP configuration errors might easily corrupt routing information of the whole Internet. If, however, you have to do it anyway, you MUST use strict distribute-lists with explicit permits (or route-maps) for redistribution. Here is an example for a Cisco configuration: router bgp 64100 aggregate-address 192.168.0.0 255.255.192.0 summary-only aggregate-address 172.16.0.0 255.254.0.0 summary-only redistribute igrp 64100 route-map origin-AS64100 ! ! or: ! redistribute igrp 64100 ! distribute-list 10 out igrp 64100 ! route-map origin-AS64100 permit 10 match ip address 10 ! access-list 10 permit 192.168.0.0 0.0.63.0 access-list 10 permit 172.16.0.0 access-list 10 permit 172.17.0.0 This example would generate one route 192.168/18 and one route 172.16/15 if any of the contained networks is in the IGP. 12. I am multihomed to three ISPs and can only CIDRize to two of them but to the third I need to still announce specific nets. What damage will this do to my AS? No damage can be done if the non-CIDR peer does not further announce your specifics to the global Internet. If your non-CIDR ISP DOES announce your specifics to the global Internet those specifics will have preference over the less specifics and therefore all traffic to you will get routed through the non-CIDR ISP. 13. I don't want to CIDRize. Can someone do proxy aggregation for me? Proxy aggregation should only be done with great care and should be avoided if you are not single-homed ! If you are single-homed ask your ISP. Others may proxy aggregate over your address range without your consent, and send your traffic over paths/links not of your choosing. Use of Routing Registries may help to identify and correct these problem areas. 14. What routers on the market today do support CIDR (classless routing)? Routers that are capable of handling CIDR are: - all Cisco routers running 10.0 or higher - all Bay Networks routers running 8.01 or higher - 3Com Netbuilder II and Netbuilder Remote Office - Telebit EMPB - Unix w/ BSD/OS 2.0 w/ gated 3.5alpha_11 + radix-fixes - IBM 2210 routers 15. How do I reach other parts of a subnetted old-style network when I have only partial routing information for that same old-style network?" There are actually three ways to solve this particular problem with Cisco's software. Which of them applies will depend on what software version is involved: o Preferred solution: turn on "ip classless" in your routers and use a default route inside your AS. The "ip classless" command prevents the existence of a single "subnet" route from blocking access via the default route to other subnets of the same old-style network. o Workaround for 9.1 or later software where the "ip classless" command is not available: install a "default network route" like this: "ip route 39.0.0.0 255.0.0.0 next-hop" along the axis your default route would normally take. o Workaround for 9.0 or older software: create a "default subnet route": "ip route 39.x.y.0 next-hop" combined with "ip default-network 39.x.y.0", otherwise as the 9.1 fix. Both of the latter solutions rely on static routes, and in the long run these will be impossible to maintain. In some topologies the use of static routes can be a problem (e.g. if you have more than one possible exit point from your AS to choose from). Supplemental information ------------------------ The following information is presented as supplemental information that is related to the CIDRization process. 16. What is the Internet Routing Registry? The IRR is a way for ASN's to publicize their own intended routing policies without having to request a change from a go-between. The RAdb which stands for the Routing Arbiter Data Base, which is part of the IRR, is part of a joint project between Merit and ISI. For full details contact: http://www.ra.net/routing.arbiter/RA/index.html. The Routing Arbiter is a project of the US National Science Foundation. As part of that project, it runs a routing registry database. That database (the RAdb) forms part of the IRR collection of databases. The RIPE database is not part of the RAdb but does participate in the IRR. At present, there are five entities that contribute to the IRR effort and more are expected. Today, all the contributing registries use the RIPE-181 database format. All IRR participants can be contacted via automail handlers that accept batch updates via email. An example of a routing update appears below: password: xxxxxxxx *rt: 138.134.0.0/16 *de: NET-IEC *or: AS378 *mb: AS378-MNT *ch: hank at aristo.tau.ac.il 950724 *so: RIPE The *rt: tag identifies the net and the routing policy is based on *or: tag. An example of a routing policy is presented below: aut-num: AS378 descr: ILAN descr: Israeli Academic and Research Network as-in: from AS1755 100 accept ANY as-in: from AS174 100 accept ANY as-in: from AS3339 100 accept AS3339 as-out: to AS1755 announce AS378 AS3339 as-out: to AS174 announce AS378 AS3339 as-out: to AS3339 announce ANY default: AS174 10 default: AS1755 20 default: AS3339 30 guardian: HANK at vm.biu.ac.il mnt-by: AS378-MNT admin-c: Hank Nussbacher tech-c: Hank Nussbacher changed: hank at vm.tau.ac.il 950627 source: RIPE For further details read over ripe-120.ps, ripe-121.ps and ripe-181.ps (via anonymous ftp from info.ripe.net/ripe/docs). |17. Are there any statistics available as to aggregation in the | Internet? | COUNTS OF RADB PREFIXES BY LENGTH - The number of Route objects | registered in the RADB, with active and withdrawn routes listed | by prefix length. Data from the current week is available from: | | ftp://ftp.ra.net/routing.arbiter/radb/reports/ | counts-by-prefix/Summarize_prefix.current | | Reports from previous weeks are available from: | | ftp://ftp.ra.net/routing.arbiter/radb/reports/ | counts-by-prefix/summarize_prefix.yymmdd | | IRR ROUTES SUMMARIZED BY PREFIX LENGTH WITH AGGREGATION - A | summary of unique prefixes registered in the IRR. Routes are | summarized by the first octet of the network number. If routes | within a prefix can be aggregated, a count is printed for each | prefix length that has a different count after aggregation. Data | from the current week is available from: | | ftp://ftp.ra.net/routing.arbiter/radb/reports/ | IRR_profile/IRR_Profile.current | | Reports from previous weeks are available from: | | ftp://ftp.ra.net/routing.arbiter/radb/reports/ | IRR_profile/IRR_Profile.yymmdd 18. How do I update the registered routing information for my ASN? You need to submit a "route" object update and perhaps an "aut-num" object update (see examples above). Route objects add new nets to your autonomous system (or you can remove nets from your autonomous system) and the Autonomous-system object describes the type of routing you wish to have. 19. Which Routing database takes precedence? RIPE? RADB? MCI? Do I have to update all of them? Each provider is allowed to select the preference order for authentic data. For example, ANS uses the following precedence: ANS, CANET, MCI, RIPE, RADB If there are two routes (with different origins) within one database, the changed date is used as a tiebreaker. Else, only database precedence is used. Thus, if the RADB entry has a more recent changed date than the RIPE, ANS will use the RIPE entry. You should only have to register in one of the IRR component databases. | There is a report which shows all routes in the RADB for a specified | AS and whether there are any duplicate routes in other IRR | registries or any aggregates which cover the route (in any of the | registries, including the RADB): | | http://www.ra.net/cgi-bin/ra/radb-duplicates.pl 20. How do I check what is registered in the IRR? The tool to use is whois. A few examples make the command self explanatory: whois -h whois.ra.net 128.228.0.0 whois -h whois.ripe.net as378 whois -h whois.canet.ca 142.77.0.0 | There is an easy Web interface to query and update the IRR: | | http://nap-roma.uni.net/cgi-bin/whois 21. Is there a tool to automatically create route filters based on IRR information? rlc is a route list compiler which is a subset of nlc/alc that allows the generation of route based filters (cisco access- lists) by extracting the nets belonging to an AS or AS MACRO from a routing database (i.e. Ripe Routing Database). In addition, it supports a limited set of functions to generate AS based filter lists. rlc is fully classless, and hence supports CIDR routes and subnets, as well as host routes. Source: ftp://dxcoms.cern.ch/pub/ripe-routing-wg Author: Jean-Michel Jouanigot, CERN |22. What other tools are available in the CIDR world? | A web version of this information can be located at: | http://www.ra.net/~ra/tools | | ------------------------ | Online Tools and Reports | ------------------------ | | IRRWeb | | This graphical interface into the Internet Routing Registry makes | it possible to use the Web to query the IRR and update RADB AS | objects, Route objects, and Maintainer objects. Users can enter | any value that can be submitted through a whois query, such as an | AS number, network IP address, or maintainer. IRRWeb then displays | the corresponding AS objects, Route objects, or Maintainer objects | from the various registries in the IRR. Authorized maintainers can | edit the objects directly; IRRWeb performs a cursory pre-check and | mails the revised object to auto-dbm at ra.net. The user then | receives e-mail from auto-dbm confirming and displaying the revised | object, or explaining why the object was rejected. | | See http://www.ra.net/cgi-bin/ra/query-radb.pl | | Source code is available at | ftp://ftp.ra.net/routing.arbiter/tools/irrweb.tar.gz | | | Route History Server | | The Route History Server provides a mechanism for tracking | the announce/withdraw history of a given prefix for the last 24 | hours. The History Server peers with the route servers at | each NAP and records all BGP updates in History Server/Route | Server peering session. | | See http://www.ra.net/cgi-bin/ra/rshist.pl | | | ----------------------- | Tools Available for FTP | ----------------------- | | RSd | | The Route Server daemon (RSd) is an enhanced version of | the GateD routing software that provides multiples views of | routing information. | The software provides a mechanism for network service provides | to off-load the computational complexity of routing policy | calculations from their routers. RSd supports configuration and | transparent passing of BGP MEDs. The software also supports | BGP route flap dampening. | | Available at ftp://ftp.ra.net/routing.arbiter/tools/rsd.tar.gz | | | Peval | A policy evaluator that inputs a RIPE-181 policy | expression, performs essential background | calculations such as symbolic evaluations and | expansions, and outputs another RIPE-181 policy | expression that is used by other tools, such as | RTConfig. | | Available as part of the RAToolSet at | ftp://ftp.ra.net/routing.arbiter/tools/RAToolSet | | | RTConfig | A router configuration tool that can be used by | providers to generate router configs directly from | the RADB or other IRR registries. Currently in | production use for the RA Route Servers, ANSNET, and | CA*net, RTConfig is a front-end tool that uses peval | and radbserver transparently to users. | | Available as part of the RAToolSet at | ftp://ftp.ra.net/routing.arbiter/tools/RAToolSet | | | rrc2r/rrmerge | This Cisco-to-RIPE-181 conversion package makes it possible for | users to convert Cisco router configuration files to RIPE-181 | objects that can be submitted to the Internet Routing Registry | (IRR). The Cisco access-list can be converted into an explicit set | of nets embedded in an AS object or represented as a community. | The RADBserver is queried for any missing or previously registered | information. | | Available at | ftp://ftp.ra.net/routing.arbiter/tools/RAToolSet/rrc2r-0.2.tar.gz | | | CiscoBGP | IRR users have long recognized the need for tools that check the | IRR against routes actually propagated in the Internet. CiscoBGP | obtains and analyzes routing information from production Ciscos, | and compares the data with routes in the IRR. The software also | flags prefixes that are reserved by RFC 1597, Address Allocation | for Private Internets. | | Available as part of the MRT software distribution at | http://www.merit.edu/~mrt | | | BGPCheck | BGPCheck obtains and analyzes routing information from BGP4 | peering sessions, and compares the data with routes in the IRR. The | software also flags prefixes that are reserved by | RFC 1597, Address Allocation for Private Internets. | | Available as part of the MRT software distribution at | http://www.merit.edu/~mrt | | | PRtraceroute | The 'prtraceroute' tool is a powerful form of traceroute that | displays the Autonomous Systems that a packet traverses. | PRtraceroute was developed by the Pride project. | | A version of prtraceroute that queries the RADB is available at | ftp://ftp.ra.net/routing.arbiter/pride/prtraceroute-2.0beta2.shar.gz | | | ------------------ | Tool Announcements | ------------------ | PGP-Based Radb Authentication | Follow these steps to take advantage of the new RADB support for | PGP-based digital signatures: | | 1. Register your public key with the Routing Arbiter Service. | 2. Modify your Maintainer object to reflect your use of digital | signatures. | 3. Use PGP to sign your RADB transactions. | | For detailed instructions, see: | http://www.ra.net/routing.arbiter/RA/RADB.tools.docs/pgp.html Contributors: Christian Panigl - Vienna University, Austria Bill Manning - ISI Tony Li - Cisco Systems Havard Eidnes - SINTEF, Norway Yakov Rekhter - Cisco Systems | Craig Labovitz - Merit Network