From ncc at ripe.net Mon Nov 1 13:03:19 1999 From: ncc at ripe.net (NCC Role Account) Date: Mon, 1 Nov 1999 13:03:19 +0100 (CET) Subject: ICANN Welcomes New Directors Message-ID: <199911011203.NAA00704@birch.ripe.net> Reply to: ncc From: RIPE NCC Staff X-Organisation: RIPE Network Coordination Centre X-Phone: +31 20 535 4444 X-Fax: +31 20 535 4445 Date: Mon, 01 Nov 1999 13:03:19 +0100 Sender: ncc at ripe.net [ Apologies for any duplicates] Dear Colleagues, FYI, in the message attached below please find the ICANN announcement containing the list of new Directors appointed to the ICANN Board by the three Supporting Organisations. For biographies of each Director and other relevant URLs please consult the list of links provided in the ICANN announcement. The RIPE NCC would also like to announce the formal Website for the Address Supporting Organisation. APNIC has kindly volunteered to host the ASO Website that can be reached at: http://www.aso.icann.org Regards, Paul Rendek ----- From: "Andrew McLaughlin" To: "Icann-Announce" Subject: [AC-COORD] ICANN Welcomes New Directors Date: Thu, 28 Oct 1999 01:38:11 -0700 ICANN is pleased to announce that nine new Directors have been named to the Board by its three supporting organizations. DIRECTORS SELECTED BY THE ADDRESS SUPPORTING ORGANIZATION (ASO): - Robert Blokzijl - Ken Fockler - Pindar Wong DIRECTORS SELECTED BY THE DOMAIN NAME SUPPORTING ORGANIZATION (DNSO): - Amadeu Abril I Abril - Jonathan Cohen - Alejandro Pisanty DIRECTORS SELECTED BY THE PROTOCOL SUPPORTING ORGANIZATION (PSO): - Jean-Francois Abramatic - Vinton G. Cerf - Philip Davidson The members of the Initial Board congratulate and welcome these new Directors, and thank the numerous participants in the supporting organizations who worked hard to complete the nomination and voting processes prior to ICANN's upcoming round of meetings in Los Angeles, November 1-4. Andrew McLaughlin ICANN LINKS - ICANN: - Biographical information on the new directors: - Address Supporting Organization: - Domain Name Supporting Organization: - Protocol Supporting Organization: - ICANN Los Angeles meetings: From ripe-dbm at ripe.net Mon Nov 8 18:01:55 1999 From: ripe-dbm at ripe.net (RIPE Database Administration) Date: Mon, 08 Nov 1999 18:01:55 +0100 Subject: Top 100 Maintainers List 19991108 Message-ID: <199911081701.SAA06416@birch.ripe.net> Dear list members, This is biweekly report on inconsistent objects in the RIPE whois database. The first 100 maintainers are listed as a table below sorted according to number of their inconsistent objects in the database. The rest of the maintainers which have inconsistent objects can be found at http://www.ripe.net/db/state/mntnerreport1.html You can find further information about the Consistency Project at http://www.ripe.net/db/state/ Regards, RIPE NCC Database Group =============================================================== Maintainer no of name inconsistent objects 1 DENIC-P 36438 http://www.ripe.net/db/state/maintainers/DENIC-P.html 2 XLINK-MNT 33302 http://www.ripe.net/db/state/maintainers/XLINK-MNT.html 3 DK-DOMREG 5189 http://www.ripe.net/db/state/maintainers/DK-DOMREG.html 4 INTERNET-NOC 2959 http://www.ripe.net/db/state/maintainers/INTERNET-NOC.html 5 ROKA-P 2849 http://www.ripe.net/db/state/maintainers/ROKA-P.html 6 DTAG-NIC 2644 http://www.ripe.net/db/state/maintainers/DTAG-NIC.html 7 FR-NIC-MNT 2289 http://www.ripe.net/db/state/maintainers/FR-NIC-MNT.html 8 SCHLUND-P 1645 http://www.ripe.net/db/state/maintainers/SCHLUND-P.html 9 ECORE-NET 1582 http://www.ripe.net/db/state/maintainers/ECORE-NET.html 10 BO-DOMREG 1483 http://www.ripe.net/db/state/maintainers/BO-DOMREG.html 11 NACAMAR-NOC 1423 http://www.ripe.net/db/state/maintainers/NACAMAR-NOC.html 12 WWW-MNT 1140 http://www.ripe.net/db/state/maintainers/WWW-MNT.html 13 DENIC-N 1063 http://www.ripe.net/db/state/maintainers/DENIC-N.html 14 AS1849-MNT 897 http://www.ripe.net/db/state/maintainers/AS1849-MNT.html 15 DREIMARK49-MNT 658 http://www.ripe.net/db/state/maintainers/DREIMARK49-MNT.html 16 ABCAG-MNT 602 http://www.ripe.net/db/state/maintainers/ABCAG-MNT.html 17 SEKTORNET-MNT 556 http://www.ripe.net/db/state/maintainers/SEKTORNET-MNT.html 18 CSL-MNT 523 http://www.ripe.net/db/state/maintainers/CSL-MNT.html 19 HIGHSPEED-DOM 519 http://www.ripe.net/db/state/maintainers/HIGHSPEED-DOM.html 20 DFN-NTFY 517 http://www.ripe.net/db/state/maintainers/DFN-NTFY.html 21 DKNET-MNT 498 http://www.ripe.net/db/state/maintainers/DKNET-MNT.html 22 NACAMAR-RES 449 http://www.ripe.net/db/state/maintainers/NACAMAR-RES.html 23 SDT-NOC 392 http://www.ripe.net/db/state/maintainers/SDT-NOC.html 24 GLOBAL-MNT 390 http://www.ripe.net/db/state/maintainers/GLOBAL-MNT.html 25 DE-VOSS 374 http://www.ripe.net/db/state/maintainers/DE-VOSS.html 26 DIGITALWEB-MNT 369 http://www.ripe.net/db/state/maintainers/DIGITALWEB-MNT.html 27 AS1267-MNT 350 http://www.ripe.net/db/state/maintainers/AS1267-MNT.html 28 TDK-MNT 349 http://www.ripe.net/db/state/maintainers/TDK-MNT.html 29 NACAMAR-POP 346 http://www.ripe.net/db/state/maintainers/NACAMAR-POP.html 30 RAIN-TRANSPAC 344 http://www.ripe.net/db/state/maintainers/RAIN-TRANSPAC.html 31 AS6678-MNT 334 http://www.ripe.net/db/state/maintainers/AS6678-MNT.html 32 IDNET-MNT 327 http://www.ripe.net/db/state/maintainers/IDNET-MNT.html 33 KNIPP-NOC-MNT 296 http://www.ripe.net/db/state/maintainers/KNIPP-NOC-MNT.html 34 IL-P 292 http://www.ripe.net/db/state/maintainers/IL-P.html 35 RAK-NET 278 http://www.ripe.net/db/state/maintainers/RAK-NET.html 36 MARIDAN-P 276 http://www.ripe.net/db/state/maintainers/MARIDAN-P.html 37 GIGABELL-MNT 275 http://www.ripe.net/db/state/maintainers/GIGABELL-MNT.html 38 INX-MNT 274 http://www.ripe.net/db/state/maintainers/INX-MNT.html 39 NETCOLOGNE-MNT 269 http://www.ripe.net/db/state/maintainers/NETCOLOGNE-MNT.html 40 FR-EASYNET 254 http://www.ripe.net/db/state/maintainers/FR-EASYNET.html 41 AS1717-MNT 250 http://www.ripe.net/db/state/maintainers/AS1717-MNT.html 42 AS3233-MNT 246 http://www.ripe.net/db/state/maintainers/AS3233-MNT.html 43 WESPE-MNT 240 http://www.ripe.net/db/state/maintainers/WESPE-MNT.html 44 AS5617-MNT 239 http://www.ripe.net/db/state/maintainers/AS5617-MNT.html 45 FREENAME-NOC 239 http://www.ripe.net/db/state/maintainers/FREENAME-NOC.html 46 EUROCONNECT 231 http://www.ripe.net/db/state/maintainers/EUROCONNECT.html 47 SL-CUS-MNT 229 http://www.ripe.net/db/state/maintainers/SL-CUS-MNT.html 48 NDH-P 221 http://www.ripe.net/db/state/maintainers/NDH-P.html 49 AS5378-MNT 214 http://www.ripe.net/db/state/maintainers/AS5378-MNT.html 50 IMAGINET-NOC-MNT 212 http://www.ripe.net/db/state/maintainers/IMAGINET-NOC-MNT.htm 51 AS2120-MNT 211 http://www.ripe.net/db/state/maintainers/AS2120-MNT.html 52 AT-DOM-MNT 208 http://www.ripe.net/db/state/maintainers/AT-DOM-MNT.html 53 OLEANE-NOC 208 http://www.ripe.net/db/state/maintainers/OLEANE-NOC.html 54 IWAY-NOC 205 http://www.ripe.net/db/state/maintainers/IWAY-NOC.html 55 TRMD-MNT 201 http://www.ripe.net/db/state/maintainers/TRMD-MNT.html 56 AS5427-MNT 199 http://www.ripe.net/db/state/maintainers/AS5427-MNT.html 57 AS1899-MNT 198 http://www.ripe.net/db/state/maintainers/AS1899-MNT.html 58 IBGNET 196 http://www.ripe.net/db/state/maintainers/IBGNET.html 59 MBT-MNT 193 http://www.ripe.net/db/state/maintainers/MBT-MNT.html 60 AS2529-MNT 187 http://www.ripe.net/db/state/maintainers/AS2529-MNT.html 61 SKYNETBE-MNT 184 http://www.ripe.net/db/state/maintainers/SKYNETBE-MNT.html 62 IT-NIC 180 http://www.ripe.net/db/state/maintainers/IT-NIC.html 63 ROM-MIKNET 168 http://www.ripe.net/db/state/maintainers/ROM-MIKNET.html 64 AS2871-MNT 167 http://www.ripe.net/db/state/maintainers/AS2871-MNT.html 65 DK-NIC 161 http://www.ripe.net/db/state/maintainers/DK-NIC.html 66 AS1241-MNT 159 http://www.ripe.net/db/state/maintainers/AS1241-MNT.html 67 EU-IBM-NIC-MNT2 158 http://www.ripe.net/db/state/maintainers/EU-IBM-NIC-MNT2.html 68 PRHO-GUARDIAN 158 http://www.ripe.net/db/state/maintainers/PRHO-GUARDIAN.html 69 ONE2ONE-MNT 155 http://www.ripe.net/db/state/maintainers/ONE2ONE-MNT.html 70 NETTUNO 149 http://www.ripe.net/db/state/maintainers/NETTUNO.html 71 OMNILINK-MNT 143 http://www.ripe.net/db/state/maintainers/OMNILINK-MNT.html 72 AS5551-MNT 138 http://www.ripe.net/db/state/maintainers/AS5551-MNT.html 73 NNCC 128 http://www.ripe.net/db/state/maintainers/NNCC.html 74 AS6721-MNT 119 http://www.ripe.net/db/state/maintainers/AS6721-MNT.html 75 EVOSYS-MNT 112 http://www.ripe.net/db/state/maintainers/EVOSYS-MNT.html 76 ISMA-MNT 111 http://www.ripe.net/db/state/maintainers/ISMA-MNT.html 77 AS3292-MNT 110 http://www.ripe.net/db/state/maintainers/AS3292-MNT.html 78 ISTLD-MNT 109 http://www.ripe.net/db/state/maintainers/ISTLD-MNT.html 79 ROSNIIROS-MNT 103 http://www.ripe.net/db/state/maintainers/ROSNIIROS-MNT.html 80 ISB-MNT 102 http://www.ripe.net/db/state/maintainers/ISB-MNT.html 81 SEICOM-MNT 99 http://www.ripe.net/db/state/maintainers/SEICOM-MNT.html 82 ODN-MNT 93 http://www.ripe.net/db/state/maintainers/ODN-MNT.html 83 ICMS-NOC-MAINTAINER 92 http://www.ripe.net/db/state/maintainers/ICMS-NOC-MAINTAINER. 84 AS8875-MNT 91 http://www.ripe.net/db/state/maintainers/AS8875-MNT.html 85 MDA-Z 91 http://www.ripe.net/db/state/maintainers/MDA-Z.html 86 INETWIRE-MNT 88 http://www.ripe.net/db/state/maintainers/INETWIRE-MNT.html 87 PROFI-MNT 87 http://www.ripe.net/db/state/maintainers/PROFI-MNT.html 88 COMMPLEX-MNT 85 http://www.ripe.net/db/state/maintainers/COMMPLEX-MNT.html 89 TINET-NOC 83 http://www.ripe.net/db/state/maintainers/TINET-NOC.html 90 TPNET 81 http://www.ripe.net/db/state/maintainers/TPNET.html 91 KDT-MNT 80 http://www.ripe.net/db/state/maintainers/KDT-MNT.html 92 GARR-LIR 79 http://www.ripe.net/db/state/maintainers/GARR-LIR.html 93 WEB4YOU-MNT 79 http://www.ripe.net/db/state/maintainers/WEB4YOU-MNT.html 94 JIPS-NOSC 78 http://www.ripe.net/db/state/maintainers/JIPS-NOSC.html 95 PSINET-UK-SYSADMIN 77 http://www.ripe.net/db/state/maintainers/PSINET-UK-SYSADMIN.h 96 MAINT-AS3352 75 http://www.ripe.net/db/state/maintainers/MAINT-AS3352.html 97 KAMP-MNT 71 http://www.ripe.net/db/state/maintainers/KAMP-MNT.html 98 SPACENET-P 71 http://www.ripe.net/db/state/maintainers/SPACENET-P.html 99 GLOBAL-ONE 69 http://www.ripe.net/db/state/maintainers/GLOBAL-ONE.html 100 CU-MNT 68 http://www.ripe.net/db/state/maintainers/CU-MNT.html From nurani at ripe.net Wed Nov 17 10:51:14 1999 From: nurani at ripe.net (Nurani Nimpuno) Date: Wed, 17 Nov 1999 10:51:14 +0100 Subject: IP assignment for virtual webhosting Message-ID: <199911170951.KAA22387@x7.ripe.net> Dear LIR-WG, We would like to hear your opinions on the issue of IP assignments for virtual webhosting. The current policy is rather old and in the meantime a lot of things have changed; most importantly the market for webhosting products, as well as the development of the HTTP protocol and related software. TERMINOLOGY Before we begin, however, we would like to address the issue of terminology for this subject. The term 'virtual webhosting' is being used a lot but it is often not clear in which way it should be interpreted. We suggest the following terminology: Server: A physical computer with an operating system installed on it. This could be UNIX, Windows, Mac, or something else. The webserver runs as an application on this OS. Webserver: An application program that accepts connections in order to service requests by sending back responses. That is, a piece of software that runs on a physical server. Examples of webservers are Apache, IIS, and Stronghold. User agent / Client: The client that initiates a request. These are often browsers, editors, spiders (web-traversing robots), or other end-user tools. Hostname: A nameserver entry that resolves to an IP address. This could be an A or a CNAME record. Virtual host: A hostname resolving to the IP address of a server, the webserver of which handles several hostnames. IP-based virtual hosting: Many hostnames hosted on the same server, one IP address for each hostname. Namebased virtual hosting: Many hostnames hosted on the same server, all hostnames resolve to the same IP address. OUR SUGGESTION The RIPE NCC has followed the deployment of HTTP 1.1 closely over the past year. According to recent surveys, a vast majority of clients now support HTTP 1.1 (namebased HTTP requests). It is our belief that the majority of webserver applications support namebased webhosting as well. In recent years we have seen a boom in the registration of second-level domains. This has led to a great demand for webhosting services. Using one IP address per domain uses an enormous amount of IP addresses. With HTTP 1.1 this is no longer necessary. We therefore suggest to promote namebased webhosting and to change the current policy so that IP addresses can no longer be assigned for IP-based webhosting. Please provide us with any feedback or comments you might have. Kind regards, Nurani Nimpuno (Registration Services Manager) and Simon Skals (Hostmaster) RIPE NCC From ck at toplink.net Wed Nov 17 11:23:28 1999 From: ck at toplink.net (Christian Kratzer) Date: Wed, 17 Nov 1999 11:23:28 +0100 (CET) Subject: IP assignment for virtual webhosting In-Reply-To: <199911170951.KAA22387@x7.ripe.net> Message-ID: Hi, On Wed, 17 Nov 1999, Nurani Nimpuno wrote: [snipp] > OUR SUGGESTION > > The RIPE NCC has followed the deployment of HTTP 1.1 closely over the past > year. According to recent surveys, a vast majority of clients now support > HTTP 1.1 (namebased HTTP requests). It is our belief that the majority of > webserver applications support namebased webhosting as well. > > In recent years we have seen a boom in the registration of second-level > domains. This has led to a great demand for webhosting services. Using one > IP address per domain uses an enormous amount of IP addresses. With HTTP > 1.1 this is no longer necessary. We therefore suggest to promote namebased > webhosting and to change the current policy so that IP addresses can no > longer be assigned for IP-based webhosting. we would very much welcome this. We successfully run HTTP host header based hosting on all our mass virtual servers. These are servers with mainly static content and some light cgi,php mysql usage. Usage of IP Addresses for virtual hosting should be restricted to purposes where this might be explicitly required for example for a SSL certificate for a server. But not for running massive hosting of "homepages". The current policy seems to allow for a LIR to enter /32 for each virtual server into the database. This is happening in a huge extent bloating up the ripe database. Needles to say that most of this behaviour is propably automated and we will see lots of duplicate person handles.... Greetings Christian Kratzer Toplink -- TopLink Internet Services GmbH ck at 171.2.195.in-addr.arpa Christian Kratzer http://www.toplink.net/ Phone: +49 7032 2701-0 Fax: +49 7032 2701-19 FreeBSD spoken here! From gyan at nl.demon.net Wed Nov 17 11:48:28 1999 From: gyan at nl.demon.net (Gyan Mathur) Date: Wed, 17 Nov 1999 11:48:28 +0100 Subject: IP assignment for virtual webhosting In-Reply-To: Your message of "Wed, 17 Nov 1999 10:51:14 +0100." <199911170951.KAA22387@x7.ripe.net> Message-ID: In response to Nurani Nimpuno: > In recent years we have seen a boom in the registration of second-level > domains. This has led to a great demand for webhosting services. Using one > IP address per domain uses an enormous amount of IP addresses. With HTTP > 1.1 this is no longer necessary. We therefore suggest to promote namebased > webhosting and to change the current policy so that IP addresses can no > longer be assigned for IP-based webhosting. I would agree with _promoting_ name-based web hosting but not with actually _prohibiting_ IP-based web hosting. We have got some clients who want to have a separate IP address for their web site so that they can point multiple domains at it, possibly domains registered by other parts of their company with a different ISP. We see this for example with customers who are multi-national companies and want www.customer.co.uk www.klant.nl , www.afdeling1.klant.nl , and www.kunde.de , all registered with different ISPs, to point to the same site. It is quicker and easier for them to use an IP address and just ask their other ISPs to change the DNS instead of having to ask us to change our web server configuration every time they add a new domain. I agree that these are special cases and we do not expect very many of them, but we would still like to have the flexibility to offer them this if they need it (and pay extra for it). (Note: This is quite separate from our present web service, where the software is out of date and only supports IP-based hosting; we are planning to withdraw this and replace it with name-based hosting for most of our customers once the existing contracts with the customers end.) Gyan Mathur Senior Systeembeheerder, Demon Internet Nederland From matthew at planet.net.uk Wed Nov 17 11:44:50 1999 From: matthew at planet.net.uk (Matthew Robinson) Date: Wed, 17 Nov 1999 10:44:50 -0000 Subject: IP assignment for virtual webhosting Message-ID: <6BF1C330AF53D311BE5D00508B09081006ABE0@PLANET01> We have been employing the policy of enforcing HTTP 1.1 IP-less virtuals for a while - only allowing IP addresses for SSL certificates. This seems to be working well. I'm told that some versions of SSL servers can support IP-less virtuals as well which is a step in the right direction. I think that the proposal is a good one and should be followed up with a policy of reclaiming the used 'virtual server' address space back. Kind regards Matthew -----Original Message----- From: Christian Kratzer [mailto:ck at toplink.net] Sent: 17 November 1999 10:23 To: Nurani Nimpuno Cc: lir-wg at ripe.net Subject: Re: IP assignment for virtual webhosting Usage of IP Addresses for virtual hosting should be restricted to purposes where this might be explicitly required for example for a SSL certificate for a server. But not for running massive hosting of "homepages". From eric at europa.online.be Wed Nov 17 11:26:54 1999 From: eric at europa.online.be (Eric) Date: Wed, 17 Nov 1999 11:26:54 +0100 (MET) Subject: IP assignment for virtual webhosting In-Reply-To: <199911170951.KAA22387@x7.ripe.net> Message-ID: Hi, I agree that every hosting provider should try to convert all it's websites to support namebased webhosting, however... SSL connections do require a seperate IP per website, and I think we will be seeing more and more of those in the near future with the emerging of e-commerce. Also for e.g. virtual FTP hosting (mostly combined with webhosting) you need a seperate IP /site. I'd rather see a very strict policy which basically denies the use of IP addresses for that purpose unless a *very* good explenation as to why is provided to the hostmaster. Just my few cents... On Wed, 17 Nov 1999, Nurani Nimpuno wrote: > OUR SUGGESTION > > The RIPE NCC has followed the deployment of HTTP 1.1 closely over the past > year. According to recent surveys, a vast majority of clients now support > HTTP 1.1 (namebased HTTP requests). It is our belief that the majority of > webserver applications support namebased webhosting as well. > > In recent years we have seen a boom in the registration of second-level > domains. This has led to a great demand for webhosting services. Using one > IP address per domain uses an enormous amount of IP addresses. With HTTP > 1.1 this is no longer necessary. We therefore suggest to promote namebased > webhosting and to change the current policy so that IP addresses can no > longer be assigned for IP-based webhosting. > > Please provide us with any feedback or comments you might have. > > Kind regards, > > Nurani Nimpuno (Registration Services Manager) and > Simon Skals (Hostmaster) > RIPE NCC > > > -- Eric Senior Network & Systems Engineer | http://www.online.be Online Internet nv | email: eric at noc.online.be . . . . . . . . . . . . . . . . . . . . . . . | Tel : +32 (0)9 244.11.11 RIPE Handle: EL357-RIPE | Fax : +32 (0)9 222.64.80 "It is not true that life is one damn thing after another -- it's one damn thing over and over." From nick at iol.ie Wed Nov 17 11:30:47 1999 From: nick at iol.ie (Nick Hilliard) Date: Wed, 17 Nov 1999 10:30:47 +0000 (GMT) Subject: IP assignment for virtual webhosting In-Reply-To: <199911170951.KAA22387@x7.ripe.net> from "Nurani Nimpuno" at Nov 17, 99 10:51:14 am Message-ID: <199911171030.KAA31709@beckett.earlsfort.iol.ie> > Please provide us with any feedback or comments you might have. This breaks both SSL hosting and assigning multiple hostnames to the same virtual host (unless each of them are configured manually). Nick -- | Nick Hilliard | nick at iol.ie | | Tel: +353 1 6046800 | Advanced Systems Architect | | Fax: +353 1 6046888 | Ireland On-Line System Operations | From cor at xs4all.net Wed Nov 17 12:26:42 1999 From: cor at xs4all.net (Cor Bosman) Date: Wed, 17 Nov 1999 12:26:42 +0100 Subject: IP assignment for virtual webhosting In-Reply-To: <199911170951.KAA22387@x7.ripe.net>; from nurani@ripe.net on Wed, Nov 17, 1999 at 10:51:14AM +0100 References: <199911170951.KAA22387@x7.ripe.net> Message-ID: <19991117122641.D7578@xs4all.nl> Hi Nurani, > OUR SUGGESTION > > The RIPE NCC has followed the deployment of HTTP 1.1 closely over the past > year. According to recent surveys, a vast majority of clients now support > HTTP 1.1 (namebased HTTP requests). It is our belief that the majority of > webserver applications support namebased webhosting as well. > > In recent years we have seen a boom in the registration of second-level > domains. This has led to a great demand for webhosting services. Using one > IP address per domain uses an enormous amount of IP addresses. With HTTP > 1.1 this is no longer necessary. We therefore suggest to promote namebased > webhosting and to change the current policy so that IP addresses can no > longer be assigned for IP-based webhosting. I believe it's a very good idea to strongly promote using namebased webhosting. We've done surveys on our own website, and found out the amount of clients connecting with 1.0 is next to nothing. So the 'old clients' excuse just isnt there. And in cases where we've had complaints, customers were more than willing to upgrade their browsers after we explain whats going on. We've had to do this like twice this year, no big deal. I dont think though that prohibiting ip based virtual hosting is a good idea. There will always be reasons to use ip based hosting. You've heard some already. But people should just have a damn good reason. Reclaiming already assigned virtual webhosting space is a little over the top. Especially in cases where it might only be 1 or 2 /24s. Ofcourse, if some ISP is using 2 /16's for virtual hosting, then it might be another matter. If reclaiming is done, I would suggest taking a very long grace period. Regards, Cor Bosman From lmb at teuto.net Wed Nov 17 12:21:28 1999 From: lmb at teuto.net (Lars Marowsky-Bree) Date: Wed, 17 Nov 1999 12:21:28 +0100 Subject: IP assignment for virtual webhosting In-Reply-To: <199911170951.KAA22387@x7.ripe.net>; from "Nurani Nimpuno" on 1999-11-17T10:51:14 References: <199911170951.KAA22387@x7.ripe.net> Message-ID: <19991117122128.W2566@pointer.teuto.de> On 1999-11-17T10:51:14, Nurani Nimpuno said: > In recent years we have seen a boom in the registration of second-level > domains. This has led to a great demand for webhosting services. Using one > IP address per domain uses an enormous amount of IP addresses. With HTTP > 1.1 this is no longer necessary. We therefore suggest to promote namebased > webhosting and to change the current policy so that IP addresses can no > longer be assigned for IP-based webhosting. > > Please provide us with any feedback or comments you might have. We would look forward to a very strong recommendation from RIPE with regard to this issue, promoting name based virtual servers. Apache can handle this perfectly (migration is quite easy too), the problem with virtual ftp servers can be "solved" with a special directory tree, encoding a username/password into the URL or something alike. All browsers I know of (even lynx, w3m) support this feature by now. Acceptance on the customer side is somehow suddenly vastly increased if we can point the customer at an official RIPE document/RFC, at least in our experience. Some "peer pressure" on browser/server developers sure would help to solve the last remaining problems with non-working SSL virtual hosting etc. Said strong recommendation may include reclaiming "wasted" address space as far as we are concerned. (But we do perfectly well with just a /27 for virtual hosting, hosting a few 100s of servers on a single IP, and haven't received a complain about this in the last 2 years. I can see how some LIRs may not look forward to renumbering a /21 full of virtual servers...) Sincerely, Lars Marowsky-Brie -- Lars Marowsky-Brie Network Management teuto.net Netzdienste GmbH From robert-spam99 at nisse.dk Wed Nov 17 12:09:07 1999 From: robert-spam99 at nisse.dk (=?ISO-8859-1?Q?Robert_Martin-Leg=E8ne?=) Date: Wed, 17 Nov 1999 12:09:07 +0100 (CET) Subject: IP assignment for virtual webhosting In-Reply-To: Message-ID: On Wed, 17 Nov 1999, LOUAIL Thierry wrote: > Promote namebased web hosting seems to me a good idea, but I do not agree to > forbid IP-based webhosting. In fact, with old user agents, any user can know > the list of all webs hosted under a single IP address. How can they do this, except by running through the entire namespace (which is often blocked from AXFR). -- Robert Martin-Leg?ne Hi! I'm a .signature virus! Copy me into your .signature to help me spread! From tlouail at ecritel.net Wed Nov 17 11:58:04 1999 From: tlouail at ecritel.net (LOUAIL Thierry) Date: Wed, 17 Nov 1999 11:58:04 +0100 Subject: IP assignment for virtual webhosting Message-ID: Hello, Promote namebased web hosting seems to me a good idea, but I do not agree to forbid IP-based webhosting. In fact, with old user agents, any user can know the list of all webs hosted under a single IP address. And for an hosting company (our main activity), it could make a fuss that one company amoung its customers knows it is hosted on the same server as one of its competitors... Regards. --------------------------------------------------------------------- Thierry LOUAIL ECRITEL Directeur Associ? www.ecritel.fr Tel: 0140612000 3 rue Pondichery PARIS 15 > -----Message d'origine----- > De: Nurani Nimpuno [SMTP:nurani at ripe.net] > Date: mercredi 17 novembre 1999 10:51 > ?: lir-wg at ripe.net > Objet: IP assignment for virtual webhosting > > Dear LIR-WG, > > We would like to hear your opinions on the issue of IP assignments for > virtual webhosting. The current policy is rather old and in the meantime > a lot of things have changed; most importantly the market for webhosting > products, as well as the development of the HTTP protocol and related > software. > > TERMINOLOGY > > Before we begin, however, we would like to address the issue of > terminology > for this subject. The term 'virtual webhosting' is being used a lot but it > > is often not clear in which way it should be interpreted. We suggest the > following terminology: > > Server: A physical computer with an operating system installed on it. This > could be UNIX, Windows, Mac, or something else. The webserver runs as an > application on this OS. > > Webserver: An application program that accepts connections in order to > service requests by sending back responses. That is, a piece of software > that runs on a physical server. Examples of webservers are Apache, IIS, > and > Stronghold. > > User agent / Client: The client that initiates a request. These are often > browsers, editors, spiders (web-traversing robots), or other end-user > tools. > > Hostname: A nameserver entry that resolves to an IP address. This could be > an A or a CNAME record. > > Virtual host: A hostname resolving to the IP address of a server, the > webserver of which handles several hostnames. > > IP-based virtual hosting: Many hostnames hosted on the same server, one IP > address for each hostname. > > Namebased virtual hosting: Many hostnames hosted on the same server, all > hostnames resolve to the same IP address. > > OUR SUGGESTION > > The RIPE NCC has followed the deployment of HTTP 1.1 closely over the past > year. According to recent surveys, a vast majority of clients now support > HTTP 1.1 (namebased HTTP requests). It is our belief that the majority of > webserver applications support namebased webhosting as well. > > In recent years we have seen a boom in the registration of second-level > domains. This has led to a great demand for webhosting services. Using one > IP address per domain uses an enormous amount of IP addresses. With HTTP > 1.1 this is no longer necessary. We therefore suggest to promote namebased > webhosting and to change the current policy so that IP addresses can no > longer be assigned for IP-based webhosting. > > Please provide us with any feedback or comments you might have. > > Kind regards, > > Nurani Nimpuno (Registration Services Manager) and > Simon Skals (Hostmaster) > RIPE NCC From Denesh.Bhabuta at Level3.com Wed Nov 17 12:10:14 1999 From: Denesh.Bhabuta at Level3.com (Bhabuta, Denesh) Date: Wed, 17 Nov 1999 11:10:14 -0000 Subject: IP assignment for virtual webhosting Message-ID: <6FA15EC018C1D211AA4C0008C70D033002C89CF1@l3londmail02.eu.l3.com> > Promote namebased web hosting seems to me a good idea, but I > do not agree to > forbid IP-based webhosting. In fact, with old user agents, > any user can know > the list of all webs hosted under a single IP address. And > for an hosting > company (our main activity), it could make a fuss that one > company amoung > its customers knows it is hosted on the same server as one of its > competitors... This is not necessarily the case... you can 'disable' that list... my own servers are at 212.15.64.41 - going to the IP address within the browser does not bring up a list of web sites hosted on there... I do agree though that we should not totally forbid IP based hosting... have the default as name-based hosting, with some good reasons required for IP based hosting... in the same way as static vs dynamic dialup IPs... Regards Denesh -- Denesh Bhabuta, AMISM European Internet Services Group Level (3) Communications Limited +44-20-7864-0498 ; denesh.bhabuta at level3.com From niels at euro.net Wed Nov 17 13:40:38 1999 From: niels at euro.net (Niels Bakker) Date: Wed, 17 Nov 1999 13:40:38 +0100 (MET) Subject: IP assignment for virtual webhosting In-Reply-To: <19991117122128.W2566@pointer.teuto.de> Message-ID: <991117133809.1857B-100000@venus.euro.net> Lars Marowsky-Bree wrote: > Some "peer pressure" on browser/server developers sure would help to solve > the last remaining problems with non-working SSL virtual hosting etc. How do you propose to implement this? The SSL handshake - including checking of the server's certificate by the browser - takes place before any data can be sent over the connection, like a Host: header. I could be wrong but as far as I know there is no way for the client to say "I expect this certificate." -- Niels. From syuval at netvision.net.il Wed Nov 17 14:22:03 1999 From: syuval at netvision.net.il (Yuval Shchory) Date: Wed, 17 Nov 1999 15:22:03 +0200 Subject: IP assignment for virtual webhosting Message-ID: <6D3354FF177DD211A6B60000F87ADD9E014B8573@ntx.netvision.net.il> Dear Nurani, It seems that there is a problem with implementing single-IP server, at least with some customers/applications. When you point a single IP to a whole server, you cannot back-resolve to all hostnames. Several of our customers REQUIRE that the IP would back-resolve to their own server's name. This request is sometimes a strategic decision, sometimes an applicative request. Regards, --- Yuval Shchory Projects Manager NetVision's Corporate Technical Support Department eMail: syuval at netvision.net.il interFAX: 03-5480255 --- From Stefan.Gasteiger at Gendorf.de Wed Nov 17 15:12:46 1999 From: Stefan.Gasteiger at Gendorf.de (Stefan.Gasteiger at Gendorf.de) Date: Wed, 17 Nov 1999 15:12:46 +0100 Subject: AW: IP assignment for virtual webhosting Message-ID: <31C2776E83B7D211A9600008C7337A2E010567C7@atlantis.gendorf.hoechst.com> Hi Nurani! I think when *prohibiting* IP-based web hosting, some of us could run in really bad trouble with SSL-based e-shops. I personally don't know a SSL-server which supports IP-less virtuals (LIRs out there - give me advice if you know one). Are there statistics, which show how much addresses are wasted by IP-based (non SSL) web hosting? Stefan Gasteiger SG5599-RIPE > -----Urspr?ngliche Nachricht----- > Von: Nurani Nimpuno [SMTP:nurani at ripe.net] > Gesendet am: Mittwoch, 17. November 1999 10:51 > An: lir-wg at ripe.net > Betreff: IP assignment for virtual webhosting > > Dear LIR-WG, > > We would like to hear your opinions on the issue of IP assignments for > virtual webhosting. The current policy is rather old and in the meantime > a lot of things have changed; most importantly the market for webhosting > products, as well as the development of the HTTP protocol and related > software. > > TERMINOLOGY > > Before we begin, however, we would like to address the issue of > terminology > for this subject. The term 'virtual webhosting' is being used a lot but it > > is often not clear in which way it should be interpreted. We suggest the > following terminology: > > Server: A physical computer with an operating system installed on it. This > could be UNIX, Windows, Mac, or something else. The webserver runs as an > application on this OS. > > Webserver: An application program that accepts connections in order to > service requests by sending back responses. That is, a piece of software > that runs on a physical server. Examples of webservers are Apache, IIS, > and > Stronghold. > > User agent / Client: The client that initiates a request. These are often > browsers, editors, spiders (web-traversing robots), or other end-user > tools. > > Hostname: A nameserver entry that resolves to an IP address. This could be > an A or a CNAME record. > > Virtual host: A hostname resolving to the IP address of a server, the > webserver of which handles several hostnames. > > IP-based virtual hosting: Many hostnames hosted on the same server, one IP > address for each hostname. > > Namebased virtual hosting: Many hostnames hosted on the same server, all > hostnames resolve to the same IP address. > > OUR SUGGESTION > > The RIPE NCC has followed the deployment of HTTP 1.1 closely over the past > year. According to recent surveys, a vast majority of clients now support > HTTP 1.1 (namebased HTTP requests). It is our belief that the majority of > webserver applications support namebased webhosting as well. > > In recent years we have seen a boom in the registration of second-level > domains. This has led to a great demand for webhosting services. Using one > IP address per domain uses an enormous amount of IP addresses. With HTTP > 1.1 this is no longer necessary. We therefore suggest to promote namebased > webhosting and to change the current policy so that IP addresses can no > longer be assigned for IP-based webhosting. > > Please provide us with any feedback or comments you might have. > > Kind regards, > > Nurani Nimpuno (Registration Services Manager) and > Simon Skals (Hostmaster) > RIPE NCC > > From sam.bradford at demon.net Wed Nov 17 15:01:06 1999 From: sam.bradford at demon.net (Sam Bradford) Date: Wed, 17 Nov 1999 14:01:06 +0000 Subject: IP assignment for virtual webhosting In-Reply-To: <19991117122641.D7578@xs4all.nl>; from cor@xs4all.net on Wed, Nov 17, 1999 at 12:26:42PM +0100 References: <199911170951.KAA22387@x7.ripe.net> <19991117122641.D7578@xs4all.nl> Message-ID: <19991117140106.A29823@demon.net> Cor Bosman (cor at xs4all.net) wrote: > Nurani Nimpuno wrote: > > We therefore suggest to promote namebased > > webhosting and to change the current policy so that IP addresses can no > > longer be assigned for IP-based webhosting. > > I believe it's a very good idea to strongly promote using namebased webhosting. > We've done surveys on our own website, and found out the amount of clients > connecting with 1.0 is next to nothing. So the 'old clients' excuse just > isnt there. And in cases where we've had complaints, customers were more > than willing to upgrade their browsers after we explain whats going on. > We've had to do this like twice this year, no big deal. Although the amount of clients connecting with 1.0 may be very little in most cases, it does still happen. We have customers specifically state that they do not want to set up http 1.1 because at the end of the day, some people will not be able to view their (and/or their clients') web sites, which is fair enough. If they want to ensure that every person possible can access their site, I believe they should have that right. And yes, then there is the issue of SSL certificates requiring a unique IP per site. John Crain, RIPE NCC's Internal Manager, told me this shouldn't be the case, but I see that others here are bringing it up as well. (Admittedly, SSL requirements are something I have no experience with.) > I dont think though that prohibiting ip based virtual hosting is a good idea. Ditto. Prohibiting is not a good thing. Requesting, advising, and preferring http 1.1 is one thing. RIPE NCC's demanding it is another and is very dictatorial. That would then lead to a prohibition on static-IPs for dial-ups, as well, I'm sure. Sam Bradford ----------------------------------------------------------------- sam bradford, hostmaster sam.bradford at demon.net Demon Internet / Thus plc e-mail: hostmaster at demon.net 322 Regents Park Road, Finchley, London N3 2QQ, UK (0181-371-1000) Herengracht 433, 1017 BR, Amsterdam, Netherlands (020-4222-000) From netmaster at space.net Wed Nov 17 15:30:30 1999 From: netmaster at space.net (Gert Doering, Netmaster) Date: Wed, 17 Nov 1999 15:30:30 +0100 Subject: IP assignment for virtual webhosting In-Reply-To: <199911170951.KAA22387@x7.ripe.net>; from nurani@ripe.net on Wed, Nov 17, 1999 at 10:51:14AM +0100 References: <199911170951.KAA22387@x7.ripe.net> Message-ID: <19991117153030.G80779@Space.Net> Hi, On Wed, Nov 17, 1999 at 10:51:14AM +0100, Nurani Nimpuno wrote: > We would like to hear your opinions on the issue of IP assignments for > virtual webhosting. The current policy is rather old and in the meantime > a lot of things have changed; most importantly the market for webhosting > products, as well as the development of the HTTP protocol and related > software. We think that HTTP/1.1 name based virtual hosting should be strongly encouraged, but we do not want to have IP based virtual hosting to be "forbidden". For pure WWW/HTTP hosting, there is no need to use IP based virtual hosting, but for customers demanding special solutions, like https/SSL, anonymous FTP servers (they want their *own* anonymous FTP server, not something like /pub//..., being able to see all other customers' servers), RealAudio service, etc., IP based virtual hosting is necessary. kind regards, Gert Doering -- SpaceNet NetMaster -- SpaceNet GmbH Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From pgoncalves at mail.telepac.pt Wed Nov 17 15:38:57 1999 From: pgoncalves at mail.telepac.pt (Pedro =?iso-8859-1?Q?Gon=E7alves?=) Date: Wed, 17 Nov 1999 14:38:57 +0000 Subject: IP assignment for virtual webhosting In-Reply-To: <199911170951.KAA22387@x7.ripe.net> Message-ID: <4.1.19991117142159.0097e460@mail.telepac.pt> Hi At 10:51 17-11-1999 +0100, Nurani Nimpuno wrote: > >OUR SUGGESTION > >The RIPE NCC has followed the deployment of HTTP 1.1 closely over the past >year. According to recent surveys, a vast majority of clients now support >HTTP 1.1 (namebased HTTP requests). It is our belief that the majority of >webserver applications support namebased webhosting as well. > >In recent years we have seen a boom in the registration of second-level >domains. This has led to a great demand for webhosting services. Using one >IP address per domain uses an enormous amount of IP addresses. With HTTP >1.1 this is no longer necessary. We therefore suggest to promote namebased >webhosting and to change the current policy so that IP addresses can no >longer be assigned for IP-based webhosting. > IMO prohibiting all use of public IP address for virtual webhosting solutions its going to be a step to far for now, since some of those addresses are used in SSL certificates. Maybe if we separate common V W hosting from Secure Web Hosting we can apply diferent policies. For example: Current Special verification Methods can be applyed for Secure Web Hosting address space and analised separatly, while the use of HTTP1.1 is promoted. Pedro Goncalves Telepac - Comunica??es Interactivas From miquels at cistron.nl Wed Nov 17 15:49:37 1999 From: miquels at cistron.nl (Miquel van Smoorenburg) Date: Wed, 17 Nov 1999 15:49:37 +0100 Subject: IP assignment for virtual webhosting In-Reply-To: <19991117140106.A29823@demon.net>; from sam.bradford@demon.net on Wed, Nov 17, 1999 at 02:01:06PM +0000 References: <199911170951.KAA22387@x7.ripe.net> <19991117122641.D7578@xs4all.nl> <19991117140106.A29823@demon.net> Message-ID: <19991117154937.B28983@cistron.nl> [apologies for the large Cc: list, not sure what to take out] According to Sam Bradford: > Although the amount of clients connecting with 1.0 may be very little in > most cases, it does still happen. > We have customers specifically state that > they do not want to set up http 1.1 because at the end of the day, some > people will not be able to view their (and/or their clients') web sites, > which is fair enough. If they want to ensure that every person possible can > access their site, I believe they should have that right. There is one thing people are forgetting to mention. This isn't about HTTP/1.1. It is about the Host: header, which is indeed in the HTTP/1.1 standard but is _also_ an allowed extension to HTTP/1.0. In fact, all HTTP/1.0 compliant browsers less than say four or five years old send this Host: header even in HTTP/1.0 requests. Netscape 1.x and up do, MSIE 3.x and up do. Is there anyone still using Netscape 0.x or MSIE 2.x ? If so, chances are that they can't view 95% of all sites anyway because of HTML shortcomings .. Mike. -- First things first, but not necessarily in that order. From clive at demon.net Wed Nov 17 16:22:30 1999 From: clive at demon.net (Clive D.W. Feather) Date: Wed, 17 Nov 1999 15:22:30 +0000 Subject: IP assignment for virtual webhosting In-Reply-To: ; from eric@europa.online.be on Wed, Nov 17, 1999 at 11:26:54AM +0100 References: <199911170951.KAA22387@x7.ripe.net> Message-ID: <19991117152230.A17583@demon.net> Eric said: > I'd rather see a very strict policy which basically > denies the use of IP addresses for that purpose unless a *very* good > explenation as to why is provided to the hostmaster. But what is a "very good explanation" ? Is RIPE going to start judging what are "good" and "bad" applications ? -- Clive D.W. Feather | Work: | Tel: +44 20 8371 1138 Internet Expert | Home: | Fax: +44 20 8371 1037 Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 377646 From lmb at teuto.net Wed Nov 17 16:38:08 1999 From: lmb at teuto.net (Lars Marowsky-Bree) Date: Wed, 17 Nov 1999 16:38:08 +0100 Subject: IP assignment for virtual webhosting In-Reply-To: <19991117152230.A17583@demon.net>; from "Clive D.W. Feather" on 1999-11-17T15:22:30 References: <199911170951.KAA22387@x7.ripe.net> <19991117152230.A17583@demon.net> Message-ID: <19991117163808.C2566@pointer.teuto.de> On 1999-11-17T15:22:30, "Clive D.W. Feather" said: > But what is a "very good explanation" ? Is RIPE going to start judging what > are "good" and "bad" applications ? Now, that would be a totally new concept for the RIPE hostmasters to decide whether to approve an inetnum request or not... ;) Sincerely, Lars Marowsky-Brie -- Lars Marowsky-Brie Network Management teuto.net Netzdienste GmbH From Denesh.Bhabuta at Level3.com Wed Nov 17 16:43:20 1999 From: Denesh.Bhabuta at Level3.com (Bhabuta, Denesh) Date: Wed, 17 Nov 1999 15:43:20 -0000 Subject: IP assignment for virtual webhosting Message-ID: <6FA15EC018C1D211AA4C0008C70D033002C89CFA@l3londmail02.eu.l3.com> > But what is a "very good explanation" ? Is RIPE going to Something along the lines of why static IP for the applicants web hosting product/services is absolutely necessary. > start judging what > are "good" and "bad" applications ? RIPE do that anyway! Regards Denesh -- Denesh Bhabuta, AMISM European Internet Services Group Level (3) Communications Limited +44-20-7864-0498 ; denesh.bhabuta at level3.com From j.kammer at eurodata.de Wed Nov 17 16:47:14 1999 From: j.kammer at eurodata.de (Juergen Kammer) Date: Wed, 17 Nov 1999 16:47:14 +0100 (CET) Subject: IP assignment for virtual webhosting In-Reply-To: <199911170951.KAA22387@x7.ripe.net> from "Nurani Nimpuno" at Nov 17, 1999 10:51:14 AM Message-ID: <199911171547.QAA21737@sambesi.infos.de> Hi, > OUR SUGGESTION > > The RIPE NCC has followed the deployment of HTTP 1.1 closely over the past > year. According to recent surveys, a vast majority of clients now support > HTTP 1.1 (namebased HTTP requests). It is our belief that the majority of > webserver applications support namebased webhosting as well. > > In recent years we have seen a boom in the registration of second-level > domains. This has led to a great demand for webhosting services. Using one > IP address per domain uses an enormous amount of IP addresses. With HTTP > 1.1 this is no longer necessary. We therefore suggest to promote namebased > webhosting and to change the current policy so that IP addresses can no > longer be assigned for IP-based webhosting. > > Please provide us with any feedback or comments you might have. > We think this is the right way to do it (btw, we are currently engaged in switching to name-based hosting, and if this is to become the official way I strongly advise a long transition period for existing servers). But an official RIPE-policy should mention the exceptions, like SSL (as long as there is no common way to do this on a named basis -- at least apache can not do it (at least, not yet)). It should be obvious that only virtual _web_-hosting is what the policy is for, and that anon ftp, real audio etc. are not what is handled by this (better to state this explicitly so noone gets a wrong impression). Of course, all these other hosting activities are in the same basket of "virtual ip based hosting only as long as name-based hosting is not technically widespread". As long as other protocols are provided on a host which is also providing the virtual web host for a domain there is no reason for not using ip-based virtual webhosting because the addresses are used up by these other protocols anyway. But the reason for IP-based hosting in these cases is clearly in the other protocols, so this should not be an issue. The "political", i.e. customer-based reasons for IPbwh are harder to handle. With a RIPE policy in place some of the reasons will no longer be an issue because we all can point at the policy ("this is how it is done, and everyone has to do it this way, so there"). I would count 'Missing DNS reverse lookup' to these. Of the remaining reasons I think we need a list to battle on so that in the end we all have the same opinions about what is a reason and what is not. If we reach consensus that there is no reason at all: even better. Regards, Juergen Kammer -- Juergen Kammer Hostmaster SaarNet InfoServe GmbH / eurodata GmbH & Co. KG Tel. +49 681 8808761 Grossblitterdorfer Str. 257-259 Fax: +49 681 8808300 D-66119 Saarbruecken Email: kammer at infoS.de,j.kammer at eurodata.de From woeber at cc.univie.ac.at Wed Nov 17 16:48:57 1999 From: woeber at cc.univie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Wed, 17 Nov 1999 16:48:57 MET Subject: IP assignment for virtual webhosting Message-ID: <009E14A4.1AF810F8.17@cc.univie.ac.at> Clive, =Eric said: => I'd rather see a very strict policy which basically => denies the use of IP addresses for that purpose unless a *very* good => explenation as to why is provided to the hostmaster. = =But what is a "very good explanation" ? Is RIPE going to start judging what =are "good" and "bad" applications ? good point! But even before going into technical or administrative details, could the NCC please provide us with - motivation and background for opening that issue - an educated guess about the absolute or relative impact on the amount of remaining unused IPv4 address space, both in prospect as well as in retrospect? Wilfried. -------------------------------------------------------------------------- Wilfried Woeber : e-mail: Woeber at CC.UniVie.ac.at Computer Center - ACOnet : Tel: +43 1 4277 - 140 33 Vienna University : Fax: +43 1 4277 - 9 140 Universitaetsstrasse 7 : RIPE-DB (&NIC) Handle: WW144 A-1010 Vienna, Austria, Europe : PGP public key ID 0xF0ACB369 __________________________________________________________________________ From amar at telia.net Wed Nov 17 17:04:19 1999 From: amar at telia.net (Amar) Date: Wed, 17 Nov 1999 17:04:19 +0100 Subject: IP assignment for virtual webhosting References: <199911170951.KAA22387@x7.ripe.net> <19991117152230.A17583@demon.net> <19991117163808.C2566@pointer.teuto.de> Message-ID: <3832D203.BD1AEFAC@telia.net> Lars Marowsky-Bree wrote: > > On 1999-11-17T15:22:30, > "Clive D.W. Feather" said: > > > But what is a "very good explanation" ? Is RIPE going to start judging what > > are "good" and "bad" applications ? > > Now, that would be a totally new concept for the RIPE hostmasters to decide > whether to approve an inetnum request or not... ;) I see some issues: * The scope to "The fair distribution of public Internet address space according to the operational needs of the end users operating networks using this address space. In order to maximize the lifetime of the public Internet address space resource, addresses must be distributed according to need, and stockpiling must be prevented. ( RIPE-185 2.2) + Keeping our customers happy so that they can get the service and usability they actually pay for. But still do this within the guidelines that exists today. We have to remember that these are the people that actually make many of us exist. + "Force" those users that can - but still hasn't bother, to upgrade to http 1.1. And who today uses big amount of address space because of this. + Define and understand those who still can not follow the proposed new guidelines. And add this into the proposal. To find a good and balanced combination of this, is imho the goal. But i fully support the idea that "close the door" on http 1.0 if not exceptional reasons applies. Regards -- amar Telia Net From Havard.Eidnes at runit.sintef.no Wed Nov 17 18:09:52 1999 From: Havard.Eidnes at runit.sintef.no (Havard.Eidnes at runit.sintef.no) Date: Wed, 17 Nov 1999 18:09:52 +0100 Subject: IP assignment for virtual webhosting In-Reply-To: Your message of "Wed, 17 Nov 1999 14:01:06 +0000" <19991117140106.A29823@demon.net> References: <19991117140106.A29823@demon.net> Message-ID: <19991117180952Z.he@runit.sintef.no> > Although the amount of clients connecting with 1.0 may be very > little in most cases, it does still happen. We have customers > specifically state that they do not want to set up http 1.1 > because at the end of the day, some people will not be able to > view their (and/or their clients') web sites, which is fair > enough. I hope this doesn't mean they don't deply http 1.1-capable servers, but that they don't actually utilize the virtual hosting functionality based on the Host: header in http 1.1? Not doing 1.1 server-side would be extremely bad for the http 1.1 clients and the general health of the network. By the way, anyone want to take bets about when the next craze about "always on" network service becomes significantly widespread, and how that will affect IP address space consumption? ;-) (No, I'm not an IPv6 advocate, if that's what you're thinking, just putting this all in some larger perspective.) - H?vard From phk at critter.freebsd.dk Wed Nov 17 17:42:32 1999 From: phk at critter.freebsd.dk (Poul-Henning Kamp) Date: Wed, 17 Nov 1999 17:42:32 +0100 Subject: IP assignment for virtual webhosting In-Reply-To: Your message of "Wed, 17 Nov 1999 15:43:20 GMT." <6FA15EC018C1D211AA4C0008C70D033002C89CFA@l3londmail02.eu.l3.com> Message-ID: <1495.942856952@critter.freebsd.dk> In message <6FA15EC018C1D211AA4C0008C70D033002C89CFA at l3londmail02.eu.l3.com>, " Bhabuta, Denesh" writes: >> But what is a "very good explanation" ? Is RIPE going to > >Something along the lines of why static IP for the applicants web hosting >product/services is absolutely necessary. > >> start judging what >> are "good" and "bad" applications ? > >RIPE do that anyway! But we can add that quite a number of LIR's seem unaware of this practice: You can find the entire list of offenders at: http://stat.cybercity.dk/ripe And a "Bad guys" list at: http://stat.cybercity.dk/ripe/bad.html #IPs LIR ----------------------- 11944 se.swipnet 1495 uk.pol 1240 uk.demon 1098 tr.superonline 751 fi.kolumbus 693 uk.pipex 633 uk.global 537 nl.euronet 460 ch.swissonline 438 pt.ipglobal 435 fr.isdnet 407 uk.force9 395 eu.eunet 392 de.maz 390 it.iunet 365 se.sunet 313 nl.nlnet 304 pl.tpsa 258 fr.proxad 249 uk.ntli 246 eu.globalone-north 243 il.euronet-rg 228 nl.versatel 225 de.rak 211 ch.petrel 209 se.transpac 202 gr.otenet 195 it.flashnet 182 se.telianet 181 de.schlund 179 at.xpoint 176 cz.cznet 171 uk.i-way 160 il.isdnnet 158 ru.sovam 155 gr.forthnet 152 si.arnes 135 fr.telecom 133 be.interpac 132 nl.xs4all 130 de.ginko 127 no.daxnet 126 ba.bihnet 125 be.wol 124 fr.iway 120 dk.euroconnect 119 de.cybernet 119 uk.xara 108 nl.demon -- Poul-Henning Kamp FreeBSD coreteam member phk at FreeBSD.ORG "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! From Toby.Williams at Level3.com Wed Nov 17 18:46:56 1999 From: Toby.Williams at Level3.com (Williams, Toby) Date: Wed, 17 Nov 1999 17:46:56 -0000 Subject: IP assignment for virtual webhosting Message-ID: <6FA15EC018C1D211AA4C0008C70D033003F068BE@l3londmail02.eu.l3.com> In a sales environment, it would certainly be easier to enforce namebased virtual web-hosting if everyone had to play by the same rules. Currently being conciencous and telling a prospect they can't have the IP addresses for virtual web hosting gets the response "well ISP xxx will provide me with them". The importance of enforcing name-based hosting is high, but I also get the feeling the amount of wasted address space elsewhere on the Internet (/16s allocated to big institutions years ago that are firewalled other than a handful of /24s?) should be a higher priority - not saying that RIPE did these allocations of course! Toby > -----Original Message----- > From: Havard.Eidnes at runit.sintef.no > [mailto:Havard.Eidnes at runit.sintef.no] > Sent: 17 November 1999 17:10 > To: Sam.Bradford at demon.net > Cc: cor at xs4all.net; nurani at ripe.net; lir-wg at ripe.net > Subject: Re: IP assignment for virtual webhosting > > > > Although the amount of clients connecting with 1.0 may be very > > little in most cases, it does still happen. We have customers > > specifically state that they do not want to set up http 1.1 > > because at the end of the day, some people will not be able to > > view their (and/or their clients') web sites, which is fair > > enough. > > I hope this doesn't mean they don't deply http 1.1-capable > servers, but that they don't actually utilize the virtual hosting > functionality based on the Host: header in http 1.1? > > Not doing 1.1 server-side would be extremely bad for the http 1.1 > clients and the general health of the network. > > By the way, anyone want to take bets about when the next craze about > "always on" network service becomes significantly widespread, and > how that will affect IP address space consumption? ;-) (No, I'm not > an IPv6 advocate, if that's what you're thinking, just putting this > all in some larger perspective.) > > > - H?vard > From woeber at cc.univie.ac.at Thu Nov 18 10:34:13 1999 From: woeber at cc.univie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Thu, 18 Nov 1999 10:34:13 MET Subject: IP assignment for virtual webhosting Message-ID: <009E1538.EB892A88.3@cc.univie.ac.at> Dear Poul-Henning, =>Something along the lines of why static IP for the applicants web hosting =>product/services is absolutely necessary. => =>> start judging what =>> are "good" and "bad" applications ? => =>RIPE do that anyway! = =But we can add that quite a number of LIR's seem unaware of this =practice: = =You can find the entire list of offenders at: = = http://stat.cybercity.dk/ripe = =And a "Bad guys" list at: = = http://stat.cybercity.dk/ripe/bad.html = =#IPs LIR =----------------------- =11944 se.swipnet = = [ ... ] you seem to imply that the number of host addresses you see (from within address blocks that happen to have "inconsistencies" in the DB objects) is directly related to the number of addresses assigned for virtual applications? I'm lost... Wilfried. From Havard.Eidnes at runit.sintef.no Thu Nov 18 14:00:50 1999 From: Havard.Eidnes at runit.sintef.no (Havard.Eidnes at runit.sintef.no) Date: Thu, 18 Nov 1999 14:00:50 +0100 Subject: IP assignment for virtual webhosting In-Reply-To: Your message of "Wed, 17 Nov 1999 17:46:56 -0000" <6FA15EC018C1D211AA4C0008C70D033003F068BE@l3londmail02.eu.l3.com> References: <6FA15EC018C1D211AA4C0008C70D033003F068BE@l3londmail02.eu.l3.com> Message-ID: <19991118140050W.he@runit.sintef.no> > The importance of enforcing name-based hosting is high, but I > also get the feeling the amount of wasted address space > elsewhere on the Internet (/16s allocated to big institutions > years ago that are firewalled other than a handful of /24s?) > should be a higher priority - not saying that RIPE did these > allocations of course! The past sins of others is no excuse to continue sinning. Besides, there was a time before "classless" technology became widespread or even available, and there actually existed prior IP address allocation policies from the registries (or back to when there only was a single registry) which were substantially different from the ones we have in use today. Regards, - H?vard From af at ins.net Thu Nov 18 14:50:30 1999 From: af at ins.net (Andreas Frackowiak) Date: Thu, 18 Nov 1999 14:50:30 +0100 (MET) Subject: IP assignment for virtual webhosting In-Reply-To: <19991118140050W.he@runit.sintef.no> from "Havard.Eidnes@runit.sintef.no" at "Nov 18, 99 02:00:50 pm" Message-ID: <199911181350.OAA22842@bra.ins.de> Havard.Eidnes at runit.sintef.no schrieb per Mail : > > The importance of enforcing name-based hosting is high, but I > > also get the feeling the amount of wasted address space > > elsewhere on the Internet (/16s allocated to big institutions > > years ago that are firewalled other than a handful of /24s?) > > should be a higher priority - not saying that RIPE did these > > allocations of course! > > The past sins of others is no excuse to continue sinning. Right. But this is not a religious matter. So that are not "sins" but "errors", and errors can often be corrected. I agree with all efforts to minimze wasting adress space in the future (so I agree to name-based Web-hosting...) but there should also be the same effort in examine errors (wasted adress space) of the past, and correcting them, if possible. > Besides, there was a time before "classless" technology became > widespread or even available, and there actually existed prior IP > address allocation policies from the registries (or back to when > there only was a single registry) which were substantially different > from the ones we have in use today. Right, and there also was a time when everyone thought, 2 year-digits in a date-field are enough. ;) That is no excuse to not try to correct the errors of the past. regards, Andreas -- INS Informationstechnik, Netzwerke und Systeme Vertriebs-GmbH Postfach 101312 (PLZ 44543), Europaplatz 14 (PLZ 44575), Castrop-Rauxel Andreas Frackowiak Phone: +49-2305-101-0 Fax: +49-2305-101-155 af at ins.de From phk at critter.freebsd.dk Thu Nov 18 14:57:19 1999 From: phk at critter.freebsd.dk (Poul-Henning Kamp) Date: Thu, 18 Nov 1999 14:57:19 +0100 Subject: IP assignment for virtual webhosting In-Reply-To: Your message of "Thu, 18 Nov 1999 10:34:13 +0700." <009E1538.EB892A88.3@cc.univie.ac.at> Message-ID: <1074.942933439@critter.freebsd.dk> In message <009E1538.EB892A88.3 at cc.univie.ac.at>, "Wilfried Woeber, UniVie/ACOn et" writes: > Dear Poul-Henning, > >=>Something along the lines of why static IP for the applicants web hosting >=>product/services is absolutely necessary. >=> >=>> start judging what >=>> are "good" and "bad" applications ? >=> >=>RIPE do that anyway! >= >=But we can add that quite a number of LIR's seem unaware of this >=practice: >=[...] > > you seem to imply that the number of host addresses you see > > (from within address blocks that happen to > have "inconsistencies" in the DB objects) > > is directly related to the number of addresses assigned for virtual > applications? I'm lost... No I merely pointed out that some LIR doesn't seem to bother much with RIPEs rules in the first place, and consequently any new rules may not stand much chance either unless breaking RIPE rules have some negative consequences... -- Poul-Henning Kamp FreeBSD coreteam member phk at FreeBSD.ORG "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! From sam.bradford at demon.net Thu Nov 18 15:37:52 1999 From: sam.bradford at demon.net (Sam Bradford) Date: Thu, 18 Nov 1999 14:37:52 +0000 Subject: IP assignment for virtual webhosting In-Reply-To: <1074.942933439@critter.freebsd.dk>; from phk@critter.freebsd.dk on Thu, Nov 18, 1999 at 02:57:19PM +0100 References: <009E1538.EB892A88.3@cc.univie.ac.at> <1074.942933439@critter.freebsd.dk> Message-ID: <19991118143752.F4962@demon.net> Poul-Henning Kamp (phk at critter.freebsd.dk) typed > No I merely pointed out that some LIR doesn't seem to bother much > with RIPEs rules in the first place, and consequently any new rules > may not stand much chance either unless breaking RIPE rules have > some negative consequences... You also don't take notice of the fact that RIPE have stated that they do not want us to update the RIPE database with our Dial-Up IPs, the majority of what you continually show in your little table... #IPs LIR ----------------------- 11944 se.swipnet 1495 uk.pol 1240 uk.demon If you want to yet again discuss this further, please e-mail hostmaster at demon.net, as this is off-topic. Better yet, please ask RIPE for confirmation... Sam Bradford ----------------------------------------------------------------- sam bradford, hostmaster sam.bradford at demon.net Demon Internet / Thus plc e-mail: hostmaster at demon.net 322 Regents Park Road, Finchley, London N3 2QQ, UK (0181-371-1000) Herengracht 433, 1017 BR, Amsterdam, Netherlands (020-4222-000) From Denesh.Bhabuta at Level3.com Thu Nov 18 18:32:50 1999 From: Denesh.Bhabuta at Level3.com (Bhabuta, Denesh) Date: Thu, 18 Nov 1999 17:32:50 -0000 Subject: IP assignment for virtual webhosting Message-ID: <6FA15EC018C1D211AA4C0008C70D033002C89D06@l3londmail02.eu.l3.com> > You also don't take notice of the fact that RIPE have stated > that they do > not want us to update the RIPE database with our Dial-Up IPs, > the majority > of what you continually show in your little table... I will agree with Sam's sentiments/comments here... RIPE indeed did say that and preferred to receive static verification tables once a week... well it was the case when I worked at Demon... Regards Denesh -- Denesh Bhabuta, AMISM European Internet Services Group Level (3) Communications Limited +44-20-7864-0498 ; denesh.bhabuta at level3.com From mir at ripe.net Thu Nov 18 19:19:39 1999 From: mir at ripe.net (Mirjam Kuehne) Date: Thu, 18 Nov 1999 19:19:39 +0100 Subject: IP assignment for virtual webhosting In-Reply-To: Your message of Thu, 18 Nov 1999 17:32:50 GMT. <6FA15EC018C1D211AA4C0008C70D033002C89D06@l3londmail02.eu.l3.com> Message-ID: <199911181819.TAA00252@birch.ripe.net> "Bhabuta, Denesh" writes: * > You also don't take notice of the fact that RIPE have stated * > that they do * > not want us to update the RIPE database with our Dial-Up IPs, * > the majority * > of what you continually show in your little table... * * I will agree with Sam's sentiments/comments here... RIPE indeed did say tha * t * and preferred to receive static verification tables once a week... well it * was the case when I worked at Demon... * Just to clarify this issue from the RIPE NCC's point of view: In general all end-user assignments need to be registered in the database. In the specific case of dial-up users the concern was raised that this could possibly disclose the entire customer list of an ISP. Therefore the regional registries together with IANA developed an alternative procedure for this specific case. This means the ISP/LIR has the choice between either registering all indiviudal dial-up assignments in the database or sending a regular update of the utilisation of these addresses. Mirjam Kuehne RIPE NCC * Regards * Denesh * -- * Denesh Bhabuta, AMISM * European Internet Services Group * Level (3) Communications Limited * +44-20-7864-0498 ; denesh.bhabuta at level3.com * From phk at critter.freebsd.dk Thu Nov 18 19:29:39 1999 From: phk at critter.freebsd.dk (Poul-Henning Kamp) Date: Thu, 18 Nov 1999 19:29:39 +0100 Subject: IP assignment for virtual webhosting In-Reply-To: Your message of "Thu, 18 Nov 1999 17:32:50 GMT." <6FA15EC018C1D211AA4C0008C70D033002C89D06@l3londmail02.eu.l3.com> Message-ID: <2815.942949779@critter.freebsd.dk> In message <6FA15EC018C1D211AA4C0008C70D033002C89D06 at l3londmail02.eu.l3.com>, "Bhabuta, Denesh" writes: >> You also don't take notice of the fact that RIPE have stated >> that they do >> not want us to update the RIPE database with our Dial-Up IPs, >> the majority >> of what you continually show in your little table... > >I will agree with Sam's sentiments/comments here... RIPE indeed did say that >and preferred to receive static verification tables once a week... well it >was the case when I worked at Demon... It doesn't change the fact that the RIPE database doesn't reflect reality. Adding ONE "ASSIGNED record, covering the entire range of addresses, stating in text that these addresses are used for bla bla bla, and that you can contact bla bla bla for actual information would make the RIPE database consistent and remove uk.demon from the list I pressume. I am sure that RIPE would ask Demon to maintain one record in the database per IP#, but I'm also sure that RIPE would not be against adding one record for the range. At least that is what they asked dk.cybercity to do for similar usage. -- Poul-Henning Kamp FreeBSD coreteam member phk at FreeBSD.ORG "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! From zeidler at xlink.net Fri Nov 19 10:05:45 1999 From: zeidler at xlink.net (Petra Zeidler) Date: Fri, 19 Nov 1999 10:05:45 +0100 Subject: abusive changes of person handles (protect your maintainer!) Message-ID: <19991119100545.A25920@xlink.net> Hi, peruse the latest case of abusive changes of person handles: person: Thomas Heubach address: FICK-AG - Pornoproductions address: Nymphomanen Str. 37 address: D-80335 Muenchen address: Germany phone: +49 190 666666 nic-hdl: TH849 remarks: Wer Frauen liebt und Fotzen leckt, remarks: der mag auch HARIBOKONFEKT. Ich liebe remarks: Frauen und lecke Fotzen, doch Haribo remarks: find ich zum kotzen. mnt-by: DTAG-NIC changed: dbaier at www-service.de 19991109 source: RIPE person: Andreas Schoberth address: FICK-AG address: D-81925 Muenchen address: Germany phone: +49 190 332 332 nic-hdl: AS48-RIPE remarks: Wenn Dir ein Maedchen remarks: - pudelnackt - remarks: von hinten an die Nudel packt, remarks: wenn Dir also gutes widerfaehrt, remarks: dann ist das einen Asbach-Uralt wert. mnt-by: FR-NIC-MNT changed: chef at nic.de 19991109 source: RIPE (those two probably being affected due to being the contacts for viag.de) Judging from an earlier case, the handles weren't password protected, some "nice and intelligent person" changed the contents and then slapped a protected maintainer on it. I'm pretty sure the above is not unique; the case I know of also slandered the subject of the handle and got a XLINK-MNT put on (which it still keeps, together with a remark that Xlink doesn't appreciate abuse of our maintainer). Apart from the obvious (auth MAIL FROM and NONE ought to be considered deprecated, and every maintainer should have its password(s)), can we please find the perpetrators and scare them a bit? ;-) Oh, and also DTAG-NIC and FR-NIC-MNT will probably want to change the mnt-by: to ECRC-MNT. kind regards, Petra Zeidler -- i.A. Petra Zeidler, Neukundenanschluss Xlink Internet Service GmbH [X] zeidler at xlink.net [X] Tel: 0721/9652-220 [X] Fax: 0721/9652-209 [X] Geschaeftsfuehrer: Michael Rotert. Amtsgericht Karlsruhe HRB 8161. [X] Auftraege erledigen wir zu unseren Allgemeinen Geschaeftsbedingungen. From joao at ripe.net Fri Nov 19 11:34:03 1999 From: joao at ripe.net (Joao Luis Silva Damas) Date: Fri, 19 Nov 1999 11:34:03 +0100 Subject: abusive changes of person handles (protect your maintainer!) In-Reply-To: <19991119100545.A25920@xlink.net> References: <19991119100545.A25920@xlink.net> Message-ID: Hi, maintainer abuse as described in Petra Zeidler's mail is something that is becoming increasingly frequent. There are two issues here: - The use of very weak protection methods (NONE and MAIL-FROM) (see *). Some people like these because all they are looking for is a notification mechanism, not a protection mechanism. The use of weak protection methods makes it easy for someone, intentionally or by accident, to override the maintainer protection. - The initial attachment of a maintainer to an object without one. In the current database, dating from more quiet days in the internet, anyone can attach any maintainer to an object that does not have a mnt-by field because that maintainer's authentication is not checked when the object does not have a mnt-by attribute. In the new database, currently in development, we are already thinking about doing the corresponding check before adding the maintainer (requiring proper authentication to add it, hopefully from the maintainer's owner). Would the community see this change in behaviour as a good thing? Best regards, Joao * Some people think otherwise. (eg see http://www.providerfrage.de/mnt.htm) ===================================================== | Joao Luis Silva Damas http://www.ripe.net | | RIPE DB Group Manager email: joao at ripe.net | | RIPE NCC | | Amsterdam | ===================================================== From woeber at cc.univie.ac.at Fri Nov 19 13:31:23 1999 From: woeber at cc.univie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Fri, 19 Nov 1999 13:31:23 MET Subject: abusive changes of person handles (protect your maintainer!) Message-ID: <009E161A.D6387CC8.3@cc.univie.ac.at> Hi Joao! >There are two issues here: >- The use of very weak protection methods (NONE and MAIL-FROM) (see *). wrt the "see *": I think they do have a point in principle. In reality (for many individuals, I suppose :-) it's still more staright-forward to fake a mail-from header than reverse-engineer a crypted password string in itself. However, given the fact that many operatinal environments these days require mail to be shipped multi-hop, the risk of disclosing the (clear text) password is greater than we might want to believe... >Would the community see this change in behaviour as a good thing? Definitely! Wilfried. From cyrille.lefevre at easynet.fr Fri Nov 19 13:37:46 1999 From: cyrille.lefevre at easynet.fr (Cyrille Lefevre) Date: Fri, 19 Nov 1999 13:37:46 +0100 Subject: abusive changes of person handles (protect your maintainer!) References: <009E161A.D6387CC8.3@cc.univie.ac.at> Message-ID: <003201bf328a$e204e330$694072c3@easynet.fr> I AGREE !!! ----- Original Message ----- From: Wilfried Woeber, UniVie/ACOnet To: Cc: ; ; Sent: Friday, November 19, 1999 2:31 PM Subject: Re: abusive changes of person handles (protect your maintainer!) > Hi Joao! > > >There are two issues here: > >- The use of very weak protection methods (NONE and MAIL-FROM) (see *). > > wrt the "see *": > I think they do have a point in principle. > In reality (for many individuals, I suppose :-) it's still more > staright-forward to fake a mail-from header than reverse-engineer a > crypted password string in itself. > > However, given the fact that many operatinal environments these days > require mail to be shipped multi-hop, the risk of disclosing the > (clear text) password is greater than we might want to believe... > > >Would the community see this change in behaviour as a good thing? > > Definitely! > > Wilfried. > From carsten.schiefner at tcpip-gmbh.de Fri Nov 19 15:25:32 1999 From: carsten.schiefner at tcpip-gmbh.de (Carsten Schiefner) Date: Fri, 19 Nov 1999 15:25:32 +0100 Subject: IP assignment for virtual webhosting References: Message-ID: <38355DDC.F338E08E@tcpip-gmbh.de> Gyan Mathur wrote: > I would agree with _promoting_ name-based web hosting but not with > actually _prohibiting_ IP-based web hosting. [...] Fully seconded! Best regards, Carsten Schiefner -- Carsten Schiefner mailto:carsten.schiefner at tcpip-gmbh.de TCP/IP GmbH, Berlin (Germany) http://www.tcpip-gmbh.de Phone: +49.30.443366-0 Fax: +49.30.443366-15 Mobile: +49.172.5425797 TCP/IP GmbH runs the Contrib.Net backbone http://www.contrib.net ====================================================================== From haug at seicom.NET Sun Nov 21 11:47:54 1999 From: haug at seicom.NET (Winfried Haug) Date: Sun, 21 Nov 1999 11:47:54 +0100 Subject: IP assignment for virtual webhosting In-Reply-To: <199911181819.TAA00252@birch.ripe.net> Message-ID: <000501bf340d$dd7c6700$02ff61c2@winni-laptop.seicom.net> Hello Mirjam > -----Original Message----- > From: owner-lir-wg at ripe.net [mailto:owner-lir-wg at ripe.net]On Behalf Of > Mirjam Kuehne > Sent: Donnerstag, 18. November 1999 19:20 > To: Bhabuta, Denesh > Cc: lir-wg at ripe.net > Subject: Re: IP assignment for virtual webhosting > > > Just to clarify this issue from the RIPE NCC's point of view: In > general all end-user assignments need to be registered in the > database. In the specific case of dial-up users the concern was raised do you check it ? do you look at all cases ? Do you have enough man-power to check everything ? What about the old assignment to the Companies, who were acting as last resort and now have a huge amount of Class-B networks, which they use NOW WITHOUT approval from RIPE ? What about assignments which were made in the past, but not used and will never be used in the public ? There are many Networks in the Routing-Table without inetnum object in the Database. route: 151.15.0.0/16 descr: INFOSTRADA origin: AS1267 mnt-by: AS1267-MNT changed: ripe-dbm at ripe.net 19990205 source: RIPE ... route: 151.82.0.0/16 descr: INFOSTRADA origin: AS1267 mnt-by: AS1267-MNT changed: ripe-dbm at ripe.net 19991110 source: RIPE This are more than 60 (!) Class B networks and there are many more in the RIPE DB ! A valid route object in the RIPE DB looks like that these networks are used or will be used. It could be an idea to check for route objects without inetnum object in the DB. Ripe could send out an email to these users requesting a valid network plan. I think we can get a lot of networks back to RIPE NCC in a very short period. There are some organisations which got assignments in the past under old conditions and circumstances inetnum: 164.16.0.0 - 164.34.0.0 netname: TELEKOM-BLK Did RIPE ever request a valid network plan ? All LIRs have to provide you network plans on request ! So before we discuss how to save adress space concerning IPs for virtual web housing, RIPE should start checking the old assignments. Just my 0,02 Winfried From mir at ripe.net Tue Nov 23 11:42:36 1999 From: mir at ripe.net (Mirjam Kuehne) Date: Tue, 23 Nov 1999 11:42:36 +0100 Subject: IP assignment for virtual webhosting In-Reply-To: Your message of Sun, 21 Nov 1999 11:47:54 +0100. <000501bf340d$dd7c6700$02ff61c2@winni-laptop.seicom.net> Message-ID: <199911231042.LAA21571@birch.ripe.net> Winfried, Thank you for the suggestions. Please be assured that the RIPE NCC puts a lot of effort in improving the consistency of the database and in the conservation of address space. We will certainly consider your suggestions in our efforts. If you have additional questions or comments, please do not hesitate to contact me directly. Kind Regards, Mirjam Kuehne Head External Services RIPE NCC "Winfried Haug" writes: * Hello Mirjam * * > -----Original Message----- * > From: owner-lir-wg at ripe.net [mailto:owner-lir-wg at ripe.net]On Behalf Of * > Mirjam Kuehne * > Sent: Donnerstag, 18. November 1999 19:20 * > To: Bhabuta, Denesh * > Cc: lir-wg at ripe.net * > Subject: Re: IP assignment for virtual webhosting * > * * > * > Just to clarify this issue from the RIPE NCC's point of view: In * > general all end-user assignments need to be registered in the * > database. In the specific case of dial-up users the concern was raised * * do you check it ? do you look at all cases ? Do you have enough man-power * to check everything ? * * What about the old assignment to the Companies, who were acting as last * resort and now have a huge amount of Class-B networks, which they use NOW * WITHOUT approval from RIPE ? * What about assignments which were made in the past, but not used and * will never be used in the public ? * * There are many Networks in the Routing-Table without inetnum object in * the Database. * * route: 151.15.0.0/16 * descr: INFOSTRADA * origin: AS1267 * mnt-by: AS1267-MNT * changed: ripe-dbm at ripe.net 19990205 * source: RIPE * * ... * route: 151.82.0.0/16 * descr: INFOSTRADA * origin: AS1267 * mnt-by: AS1267-MNT * changed: ripe-dbm at ripe.net 19991110 * source: RIPE * * This are more than 60 (!) Class B networks and there are many more in the * RIPE DB ! * * A valid route object in the RIPE DB looks like that these networks are used * or will be used. * * It could be an idea to check for route objects without inetnum object in th * e * DB. * Ripe could send out an email to these users requesting a valid network plan * . * I * think we can get a lot of networks back to RIPE NCC in a very short period. * * * There are some organisations which got assignments in the past under old * conditions and circumstances * * * inetnum: 164.16.0.0 - 164.34.0.0 * netname: TELEKOM-BLK * * Did RIPE ever request a valid network plan ? * * All LIRs have to provide you network plans on request ! So before we discus * s * how to save adress space concerning IPs for virtual web housing, RIPE shoul * d * start checking the old assignments. * * Just my 0,02 * * Winfried * * From ripe-dbm at ripe.net Tue Nov 23 22:18:30 1999 From: ripe-dbm at ripe.net (RIPE Database Administration) Date: Tue, 23 Nov 1999 22:18:30 +0100 Subject: Top 100 Maintainers List 19991123 Message-ID: <199911232118.WAA05723@birch.ripe.net> Dear list members, This is biweekly report on inconsistent objects in the RIPE whois database. The first 100 maintainers are listed as a table below sorted according to number of their inconsistent objects in the database. The rest of the maintainers which have inconsistent objects can be found at http://www.ripe.net/db/state/mntnerreport1.html You can find further information about the Consistency Project at http://www.ripe.net/db/state/ Regards, RIPE NCC Database Group =============================================================== Maintainer no of name inconsistent objects 1 DENIC-P 38445 http://www.ripe.net/db/state/maintainers/DENIC-P.html 2 XLINK-MNT 37995 http://www.ripe.net/db/state/maintainers/XLINK-MNT.html 3 DK-DOMREG 6241 http://www.ripe.net/db/state/maintainers/DK-DOMREG.html 4 INTERNET-NOC 3027 http://www.ripe.net/db/state/maintainers/INTERNET-NOC.html 5 ROKA-P 2946 http://www.ripe.net/db/state/maintainers/ROKA-P.html 6 DTAG-NIC 2764 http://www.ripe.net/db/state/maintainers/DTAG-NIC.html 7 FR-NIC-MNT 2241 http://www.ripe.net/db/state/maintainers/FR-NIC-MNT.html 8 SCHLUND-P 1688 http://www.ripe.net/db/state/maintainers/SCHLUND-P.html 9 BO-DOMREG 1534 http://www.ripe.net/db/state/maintainers/BO-DOMREG.html 10 NACAMAR-NOC 1456 http://www.ripe.net/db/state/maintainers/NACAMAR-NOC.html 11 WWW-MNT 1249 http://www.ripe.net/db/state/maintainers/WWW-MNT.html 12 DENIC-N 1051 http://www.ripe.net/db/state/maintainers/DENIC-N.html 13 ABCAG-MNT 796 http://www.ripe.net/db/state/maintainers/ABCAG-MNT.html 14 DREIMARK49-MNT 787 http://www.ripe.net/db/state/maintainers/DREIMARK49-MNT.html 15 AS1849-MNT 756 http://www.ripe.net/db/state/maintainers/AS1849-MNT.html 16 HIGHSPEED-DOM 615 http://www.ripe.net/db/state/maintainers/HIGHSPEED-DOM.html 17 ECORE-NET 600 http://www.ripe.net/db/state/maintainers/ECORE-NET.html 18 SEKTORNET-MNT 565 http://www.ripe.net/db/state/maintainers/SEKTORNET-MNT.html 19 CSL-MNT 536 http://www.ripe.net/db/state/maintainers/CSL-MNT.html 20 DFN-NTFY 521 http://www.ripe.net/db/state/maintainers/DFN-NTFY.html 21 DKNET-MNT 511 http://www.ripe.net/db/state/maintainers/DKNET-MNT.html 22 NACAMAR-RES 459 http://www.ripe.net/db/state/maintainers/NACAMAR-RES.html 23 SDT-NOC 403 http://www.ripe.net/db/state/maintainers/SDT-NOC.html 24 GLOBAL-MNT 392 http://www.ripe.net/db/state/maintainers/GLOBAL-MNT.html 25 DE-VOSS 387 http://www.ripe.net/db/state/maintainers/DE-VOSS.html 26 DIGITALWEB-MNT 369 http://www.ripe.net/db/state/maintainers/DIGITALWEB-MNT.html 27 TDK-MNT 363 http://www.ripe.net/db/state/maintainers/TDK-MNT.html 28 NACAMAR-POP 349 http://www.ripe.net/db/state/maintainers/NACAMAR-POP.html 29 RAIN-TRANSPAC 343 http://www.ripe.net/db/state/maintainers/RAIN-TRANSPAC.html 30 IDNET-MNT 338 http://www.ripe.net/db/state/maintainers/IDNET-MNT.html 31 AS1267-MNT 334 http://www.ripe.net/db/state/maintainers/AS1267-MNT.html 32 AS6678-MNT 334 http://www.ripe.net/db/state/maintainers/AS6678-MNT.html 33 RAK-NET 306 http://www.ripe.net/db/state/maintainers/RAK-NET.html 34 KNIPP-NOC-MNT 305 http://www.ripe.net/db/state/maintainers/KNIPP-NOC-MNT.html 35 IL-P 296 http://www.ripe.net/db/state/maintainers/IL-P.html 36 INX-MNT 295 http://www.ripe.net/db/state/maintainers/INX-MNT.html 37 MARIDAN-P 292 http://www.ripe.net/db/state/maintainers/MARIDAN-P.html 38 WESPE-MNT 287 http://www.ripe.net/db/state/maintainers/WESPE-MNT.html 39 OLEANE-NOC 286 http://www.ripe.net/db/state/maintainers/OLEANE-NOC.html 40 NETCOLOGNE-MNT 282 http://www.ripe.net/db/state/maintainers/NETCOLOGNE-MNT.html 41 FR-EASYNET 263 http://www.ripe.net/db/state/maintainers/FR-EASYNET.html 42 AS3233-MNT 261 http://www.ripe.net/db/state/maintainers/AS3233-MNT.html 43 GIGABELL-MNT 252 http://www.ripe.net/db/state/maintainers/GIGABELL-MNT.html 44 AS1717-MNT 249 http://www.ripe.net/db/state/maintainers/AS1717-MNT.html 45 AS5617-MNT 248 http://www.ripe.net/db/state/maintainers/AS5617-MNT.html 46 FREENAME-NOC 244 http://www.ripe.net/db/state/maintainers/FREENAME-NOC.html 47 SL-CUS-MNT 239 http://www.ripe.net/db/state/maintainers/SL-CUS-MNT.html 48 NDH-P 235 http://www.ripe.net/db/state/maintainers/NDH-P.html 49 EUROCONNECT 231 http://www.ripe.net/db/state/maintainers/EUROCONNECT.html 50 AS5378-MNT 224 http://www.ripe.net/db/state/maintainers/AS5378-MNT.html 51 IMAGINET-NOC-MNT 223 http://www.ripe.net/db/state/maintainers/IMAGINET-NOC-MNT.htm 52 AS5427-MNT 213 http://www.ripe.net/db/state/maintainers/AS5427-MNT.html 53 TRMD-MNT 212 http://www.ripe.net/db/state/maintainers/TRMD-MNT.html 54 AS2120-MNT 211 http://www.ripe.net/db/state/maintainers/AS2120-MNT.html 55 MBT-MNT 209 http://www.ripe.net/db/state/maintainers/MBT-MNT.html 56 IWAY-NOC 204 http://www.ripe.net/db/state/maintainers/IWAY-NOC.html 57 AT-DOM-MNT 201 http://www.ripe.net/db/state/maintainers/AT-DOM-MNT.html 58 IBGNET 201 http://www.ripe.net/db/state/maintainers/IBGNET.html 59 AS2529-MNT 199 http://www.ripe.net/db/state/maintainers/AS2529-MNT.html 60 AS2871-MNT 198 http://www.ripe.net/db/state/maintainers/AS2871-MNT.html 61 SKYNETBE-MNT 185 http://www.ripe.net/db/state/maintainers/SKYNETBE-MNT.html 62 IT-NIC 179 http://www.ripe.net/db/state/maintainers/IT-NIC.html 63 NETTUNO 179 http://www.ripe.net/db/state/maintainers/NETTUNO.html 64 PRHO-GUARDIAN 175 http://www.ripe.net/db/state/maintainers/PRHO-GUARDIAN.html 65 ROM-MIKNET 172 http://www.ripe.net/db/state/maintainers/ROM-MIKNET.html 66 ONE2ONE-MNT 168 http://www.ripe.net/db/state/maintainers/ONE2ONE-MNT.html 67 AS1899-MNT 166 http://www.ripe.net/db/state/maintainers/AS1899-MNT.html 68 AS1241-MNT 165 http://www.ripe.net/db/state/maintainers/AS1241-MNT.html 69 EU-IBM-NIC-MNT2 162 http://www.ripe.net/db/state/maintainers/EU-IBM-NIC-MNT2.html 70 OMNILINK-MNT 147 http://www.ripe.net/db/state/maintainers/OMNILINK-MNT.html 71 DK-NIC 140 http://www.ripe.net/db/state/maintainers/DK-NIC.html 72 AS5551-MNT 139 http://www.ripe.net/db/state/maintainers/AS5551-MNT.html 73 NNCC 130 http://www.ripe.net/db/state/maintainers/NNCC.html 74 AS6721-MNT 127 http://www.ripe.net/db/state/maintainers/AS6721-MNT.html 75 ISTLD-MNT 120 http://www.ripe.net/db/state/maintainers/ISTLD-MNT.html 76 EVOSYS-MNT 117 http://www.ripe.net/db/state/maintainers/EVOSYS-MNT.html 77 AS3292-MNT 112 http://www.ripe.net/db/state/maintainers/AS3292-MNT.html 78 ISMA-MNT 111 http://www.ripe.net/db/state/maintainers/ISMA-MNT.html 79 SEICOM-MNT 108 http://www.ripe.net/db/state/maintainers/SEICOM-MNT.html 80 KDT-MNT 104 http://www.ripe.net/db/state/maintainers/KDT-MNT.html 81 ROSNIIROS-MNT 103 http://www.ripe.net/db/state/maintainers/ROSNIIROS-MNT.html 82 ISB-MNT 101 http://www.ripe.net/db/state/maintainers/ISB-MNT.html 83 PSINET-UK-SYSADMIN 101 http://www.ripe.net/db/state/maintainers/PSINET-UK-SYSADMIN.h 84 ODN-MNT 97 http://www.ripe.net/db/state/maintainers/ODN-MNT.html 85 ICMS-NOC-MAINTAINER 93 http://www.ripe.net/db/state/maintainers/ICMS-NOC-MAINTAINER. 86 PROFI-MNT 93 http://www.ripe.net/db/state/maintainers/PROFI-MNT.html 87 COMMPLEX-MNT 91 http://www.ripe.net/db/state/maintainers/COMMPLEX-MNT.html 88 INETWIRE-MNT 90 http://www.ripe.net/db/state/maintainers/INETWIRE-MNT.html 89 MDA-Z 89 http://www.ripe.net/db/state/maintainers/MDA-Z.html 90 AS8875-MNT 88 http://www.ripe.net/db/state/maintainers/AS8875-MNT.html 91 ITNET-MNT 85 http://www.ripe.net/db/state/maintainers/ITNET-MNT.html 92 TINET-NOC 83 http://www.ripe.net/db/state/maintainers/TINET-NOC.html 93 WEB4YOU-MNT 83 http://www.ripe.net/db/state/maintainers/WEB4YOU-MNT.html 94 SPACENET-P 81 http://www.ripe.net/db/state/maintainers/SPACENET-P.html 95 TPNET 81 http://www.ripe.net/db/state/maintainers/TPNET.html 96 GARR-LIR 79 http://www.ripe.net/db/state/maintainers/GARR-LIR.html 97 JIPS-NOSC 77 http://www.ripe.net/db/state/maintainers/JIPS-NOSC.html 98 MAINT-AS3352 74 http://www.ripe.net/db/state/maintainers/MAINT-AS3352.html 99 CU-MNT 73 http://www.ripe.net/db/state/maintainers/CU-MNT.html 100 DNSNET-MNT 72 http://www.ripe.net/db/state/maintainers/DNSNET-MNT.html