May 2000 - lir-wg - mailman.ripe.net

Re: Modifying references to contact info in the RIPE DB
by Wilfried Woeber, UniVie/ACOnet 24 Jun '01

24 Jun '01

Hi Joao! >If the reference is by name then when I query the DB I will get the list of >persons with that name, right? Right. >Whether the object belongs to the person or not is not going to save this >person from being contacted. From the point of view of the database and the >user querying it, the object belongs to that person. Right >The link is via a name. > >Now we substitute the reference by name with a reference by nic handle >pointing to the same person. >What is the difference? > >ALMOST NONE except that: True, for the case where there is a strict one-to-one mapping, e.g the recursion using the name returns *one* object. What do you suggets to do with the case where the recursion, based on the names, returns a *set* of objects? I can see 2 approaches (at least): - do not perform the handle substitution for that referring object and put it on the list of those requiring human intervention - expand the xxxx-c: list (which? the tech-c:?) to refer to *all* objects, but by ref'ing their handles While human beings are quite clever in selecting the "proper" instance of a person: object (by looking at country, address, email,...) a script might be quite clueless with that respect :-) Wilfried. -------------------------------------------------------------------------- Wilfried Woeber : e-mail: Woeber(a)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 --------------------------------------------------------------------------

3 3

"ownership" on ancient network assignments?
by Alexander Bochmann 31 May '00

31 May '00

Hi, we are currently noticing a dispute of two companies over a /16 address range assigned to a predecessor of both of them in 1991 (the original company was split some time ago). We're not a party in this quarrel, but I'm curious about the status of a network that was assigned such a (comparatively) long time ago. Can someone claim to be legally entitled to own this IP address range? What is likely to happen? A. Bochmann -- FreiNet Gesellschaft fuer Informationsdienste mbH Loerracher Strasse 5a D79115 Freiburg

1 0

Auditing tool
by Stephen Burley 30 May '00

30 May '00

Hi I would just like to say the auditing tool is a great success and helps me fix problems before requesting more space thus saving lots of time and effort. I have one suggestion though, when the script shows the percentage used for our network it is still over 90% of the total used even with a /17 spare. This means we still would technically qualify for a new range of addresses ;). I was wondering could the script also show in real terms and not a percentage how much space is available in "/" notation. I know i am being a bit pedantic but its just so we do not hit the panic button when its not needed. Regards Stephen Burley UUNET EMEA Hostmaster

1 0

Delay in processing updates
by RIPE Database Administration 24 May '00

24 May '00

Dear Colleagues, We have currenly a larger update queue than usual. We expect that updates in the queue will be processed in 4-5 hours. If you have not yet received an acknowledgement to your updates, there is no need to send them again. All updates received by auto-dbm(a)ripe.net have been queued. We are sorry about the inconvenience. If you have any questions, please contact <ripe-dbm(a)ripe.net>. Regards, Engin Gunduz ____________________________ RIPE Database Administration.

1 0

RIPE Database crashes ...
by Pascal Gloor 19 May '00

19 May '00

Dear LIR's, What's up with the database ? Do you think it's normal that this machine crashes every 3-4 weeks ? Does RIPE need some more guys to manage that ? I think all LIR's whould be ok to pay RIPE a little bit more fee that RIPE may have a VERY HIGH BIGGER MTBF (Mean Time Between Failure). What do you think about that ? Or what else solution do you have guys (LIR's and RIPE)... to be continued .... Regards, Pascal PGL2-RIPE, AS6893, CH-PETREL Pascal Gloor Network Manager _________________________ SPAN(tm) / Petrel Communications SA A Cable & Wireless company Tél : + 41 22 304 47 47 Fax : + 41 22 304 47 99 E-mail : pgl(a)cw.span.ch Web : http://www.span.ch

5 4

RE: RIPE Database crashes ...
by Pascal Gloor 18 May '00

18 May '00

Mark, sure, i will do it ! but RIPE need to give me access to mirror it :-) Pascal Gloor Network Manager _________________________ SPAN(tm) / Petrel Communications SA A Cable & Wireless company Tél : + 41 22 304 47 47 Fax : + 41 22 304 47 99 E-mail : pgl(a)cw.span.ch Web : http://www.span.ch > -----Original Message----- > From: Mark Lastdrager [SMTP:mark@pine.nl] > Sent: Thursday, May 18, 2000 5:04 PM > To: Pascal Gloor > Cc: lir-wg(a)ripe.net > Subject: Re: RIPE Database crashes ... > > At Thu, 18 May 2000, owner-lir-wg(a)ripe.net wrote: > > >What do you think about that ? > >Or what else solution do you have guys (LIR's and RIPE)... > > Well, maybe you can run a mirror database and give us the hostname? > > > Mark Lastdrager > Pine Internet > > -- > email: mark(a)lastdrager.nl :: ML1400-RIPE :: tel. +31-70-3111010 > http://www.pine.nl :: RIPE RegID nl.pine :: fax. +31-70-3111011 > PGP key ID 92BB81D1 :: Dutch security news @ http://security.nl > Today's excuse: the xy axis in the trackball is coordinated with the > summer soltice

1 0

RIPE Database working normally again.
by RIPE Database Administration 18 May '00

18 May '00

Dear Colleagues, Thank you for your patience. The RIPE Database is working normally again. Updates are being processed and queries are being answered by the primary server. If you have any questions, please contact <ripe-dbm(a)ripe.net>. Daniele Arena ------------- RIPE NCC

1 0

Problems RIPE Whois Service.
by RIPE Database Administration 17 May '00

17 May '00

Dear Colleagues, (Apologies if you receive this message more than once). Earlier this evening, the main RIPE Database server crashed. Your updates are not being processed at this time, but they are being queued; there is no need to send them again. Queries are being processed by a backup server; thus, the response time may be longer than usual. We are aware of the inconvience that this causes you and we are working to restore the service as quickly as possible. We shall keep you informed. If you have any questions, please contact <ripe-dbm(a)ripe.net>. Regards, Ambrose Magee ------------- RIPE NCC

1 0

ANNOUNCEMENT: Beta 0.1 of asused-public released
by John Crain 17 May '00

17 May '00

Dear Colleagues, We, the RIPE NCC, are pleased to announced the release of the beta version of asused-public. This is a tool to summarise address space that is registered in the RIPE database. For a given list of allocations the software prints various information concerning the allocations and the assignments they contain. the software "asused-public" is based on one the NCC's internal tools. It has been revised for public release in a form that does not make use of any customer confidential information. The software which uses several perl modules, these are included, is stored in the following file: ftp://ftp.ripe.net/tools/asused-public.0.1.tar.gz We are keen to receive your feedback on the beta release. Please address your comments and/or suggestions to our Software Manager, Maldwyn Morris <Maldwyn.Morris(a)ripe.net> Yours, John LeRoy Crain Head of Internal Services RIPE NCC

3 2

RE: Warning about the size of the NEXT message
by Jorma Mellin 16 May '00

16 May '00

>As for using public address space in a private enviroment without public AS >numbers iit s very simple, private address space is limited to the ranges >as detailed in the RFC, this network is going to be global and each network >needs to be unique and using private address space would have caused >logistical nightmares. For instance it is envisaged they whould run out of >address space very quickly as 10.0.0.0/8 whould only be enough for >Europe(as have UUNET / Worlcom internal networks), also if you have >independant companies approaching the GPSM initiative from differant sides >of the globe both using 10.0.0.0/8 and then want to connect to each other >directly to enable roaming which company should renumber a multi million >node GPSM network. But the use of private AS numbers is not nearly as >difficult to administer or renumber to allow differant networks to talk to >each other. If the private address space mentioned in RFC is not enough they should go for IPv6. Because GPRS, UMTS and other stuff is brand new I see no problem to implement IPv6 in gateways (and terminals). Another issue is that roarming. Why roarming have to use unique IP numbers to work? You could use application level roarming solution as well and nobody cares if the source addr have gone trough a NAT box or not. This thing is going to get messy when we get first GPRS phones out. >BTW i find it difficult to appreciate how the use of a piece of software to >produce a technical report is a mesure of a persons RIPE compectance, i >would rather say its a measure peoples unwillingness to accept another >practical use of IP into the RIPE community. It's not about the software, it's about usability. I haven't found yet a Word application for my PDA, but I do have a browser :) Jorma

1 0

RE: Warning about the size of the NEXT message
by Jorma Mellin 16 May '00

16 May '00

>Or HTML which is readable by even more systems than PDF. >It's usually a 'one-mouse-click' action to create a proper HTML file >within this M$ word app and you're done. This M$ stuff shows how well these GSM people understand the way the Internet community works. And yet they are pleading addresses. I wonder why they are so keen to have publicly routable address space (from IPv4!) but not so worried about public AS numbers. To my ears this sounds that they haven't really though about this enough. Jorma Mellin ---------------------------------------------------------- jorma.mellin(a)teliafi.net Development Manager ; CCIE#4185 Telia Finland Inc, Network Services

2 1

Warning about the size of the NEXT message
by Vesna Manojlovic 16 May '00

16 May '00

Dear list members, Please be aware that the next message coming to the list has a Word document attachment. The attachment is rather large. It is not our practice to allow such huge messages to go to the list. We tried to find an alternative way of posting it; however, due to lack of time we did not succeed. It is important that this message reaches lir-wg before the RIPE meeting. The message is from Adrian Pauling, and the subject is "IP Adddressing & GPRS Mobile Technology deployment". Apologies once more for not being able to approve it to the list in any other way. Regards, Vesna Manojlovic RIPE NCC lists moderator

6 5

Re: IP Adddressing & GPRS Mobile Technology deployment
by Hank Nussbacher 15 May '00

15 May '00

At 16:15 10/05/00 +0100, you wrote: Can you explain why it was sent on May 10 and only hit the list on May 15? -Hank >Ladies & Gentlemen, > >At the RIPE35 meeting there was some debate regarding the requirements for >IP addressing by the GPRS Mobile technology. A small working group was >formed, and subsequently some progress has been made. The attachment >provides more information, and will be of interest to those attending the >LIR-WG at RIPE36. > <<Working_Party_Briefing_paper_GPRS_addressing.doc>> > >> Regards, >> >> Adrian F Pauling >> :-)NEL2C Internet Protocol Manager >> acd Information Systems Engineering Technical Architecture >> AFP1-RIPE / AFP-ARIN / AFP25-InterNIC >> * adrian.pauling(a)bt.com >> * +44 19 2685 1992 / +44 78 0290 4877 >

2 1

RE: IP Addressing & GPRS Mobile Technology deployment
by adrian.pauling＠bt.com 15 May '00

15 May '00

Hank & LIR-WG, there was a delay due to the size of the attachment, which invoked the lists moderator, whilst the size and necessity of mailing such a file to the list were checked. The issue of IP Addressing & GPRS Mobile Technology deployment started at RIPE 35 and will be further discussed at RIPE 36. If time had permitted a more appropriate document format and probably web based URL for people to gain the information if they desired. My unreserved apologies for sending the file(s) in a proprietary document format - I was having trouble saving the embedded files as html. My thanks to Hans Petter Holen as LIR-WG Chair for providing a URL of the minutes, and James Aldridge of KPNQwest whose URL contains all the relevant details and document(s). Regards, Adrian F Pauling :-)NEL2C Internet Protocol Manager acd Information Systems Engineering Technical Architecture AFP1-RIPE / AFP-ARIN / AFP25-InterNIC * adrian.pauling(a)bt.com * +44 19 2685 1992 / +44 78 0290 4877 British Telecommunications plc Registered Office 81 Newgate Street London EC1A 7AJ Registered in England no 1800000 > -----Original Message----- > From: Hank Nussbacher [SMTP:hank@att.net.il] > Sent: 15 May 2000 13:46 > To: adrian.pauling(a)bt.com > Cc: lir-wg(a)ripe.net > Subject: Re: IP Adddressing & GPRS Mobile Technology deployment > > At 16:15 10/05/00 +0100, you wrote: > > Can you explain why it was sent on May 10 and only hit the list on May 15? > > -Hank > > >Ladies & Gentlemen, > > > >At the RIPE35 meeting there was some debate regarding the requirements > for > >IP addressing by the GPRS Mobile technology. A small working group was > >formed, and subsequently some progress has been made. The attachment > >provides more information, and will be of interest to those attending the > >LIR-WG at RIPE36. > > <<Working_Party_Briefing_paper_GPRS_addressing.doc>> > > > >> Regards, > >> > >> Adrian F Pauling > >> :-)NEL2C Internet Protocol Manager > >> acd Information Systems Engineering Technical Architecture > >> AFP1-RIPE / AFP-ARIN / AFP25-InterNIC > >> * adrian.pauling(a)bt.com > >> * +44 19 2685 1992 / +44 78 0290 4877 > >

1 0

IP Adddressing & GPRS Mobile Technology deployment
by adrian.pauling＠bt.com 15 May '00

15 May '00

Ladies & Gentlemen, At the RIPE35 meeting there was some debate regarding the requirements for IP addressing by the GPRS Mobile technology. A small working group was formed, and subsequently some progress has been made. The attachment provides more information, and will be of interest to those attending the LIR-WG at RIPE36. <<Working_Party_Briefing_paper_GPRS_addressing.doc>> > Regards, > > Adrian F Pauling > :-)NEL2C Internet Protocol Manager > acd Information Systems Engineering Technical Architecture > AFP1-RIPE / AFP-ARIN / AFP25-InterNIC > * adrian.pauling(a)bt.com > * +44 19 2685 1992 / +44 78 0290 4877 > British Telecommunications plc > Registered Office 81 Newgate Street London EC1A 7AJ > Registered in England no 1800000

3 2

Action list and Draft minutes v1 LIR-WG 35
by Hans Petter Holen 15 May '00

15 May '00

I have now updated my "Work in progress" pages available from the LIR-WG pages http://www.ripe.net/ripe/wg/lir/index.html The draft minutes as produced by Paul Tate from the RIPE NCC has been made available http://home.sol.no/~hph/RIPE/RIPE%2035%20minutes.htm My slides from the meeting http://home.sol.no/~hph/RIPE/LIR%20WG%2035_files/frame.htm and my report to the plenary http://home.sol.no/~hph/RIPE/LIR%20WG%2035%20plenary%20report-filer/frame.ht m Please submit comments and corrections to me or the list. The huge delay is entirely my fault. Many thanks to Paul for producing the minutes ! Action list: Action Owner Status Description 35.1 Chair Publish policy document 35.2 Chair Publish election procedure 35.3 WG Subscribe lir-wg 35.4 NCC PGP Key exchange procedure 35.5 NCC Implement PGP for hostmaster mail 35.6 NCC Make db checking tool available for self audit 35.7 Chair Task Force on addresses to GPRS infrastructure -hph

1 0

Draft Agenda v 2
by Hans Petter Holen 15 May '00

15 May '00

Dear Working Group, I am terribly sorry I am so late with the preparations for next weeks RIPE meeting. This is mainly due to unforseen events on my side. Please find below a draft agenda for our upcoming working group meeting. The first version of this was presented to the plenary at the last RIPE meeting. I have removed item 6 the report from the address council item as this will be presented to the ICANN open meeting on friday. Be aware that I have not gone trough the mailinglist lately to se if there has been any requests there for items to be added. Pleas drop me a note if there are any other items that ought to be on the agenda. 1. Admin -scribe, participant list, charter, mailinglists 2. Agenda 3. Meet the RIPE NCC hostmasters 4. RIPE 35 - minutes - actions 5. Reports from the Registries - RIPE NCC - APNIC - ARIN - ICANN - Status of the Latin and AFRI NiCs 7. Presentations of candidates 8. Microallocations in the ARIN region. 9. IP addresses to GPRS infrastructure. 10. Interim report from the ICANN ad Hoc group 11. Minimum Allocation 12. Name-based webhosting Yours, Hans Petter Holen Local IR Working group Chair. ---- Hans Petter Holen, VP New Products, Scandinavia Online mailto:hph@a.sol.no Phone: +47 88 00 39 16

1 0

Summary: IP assignment for virtual webhosting
by henning.brauer＠bsmail.de 12 May '00

12 May '00

-from the http side of view, it's ok to use name based vhosts -problem: accounting There is no software package to do an !reliable! accounting on a name-based basis, Accounting per IP works fine Possible solution is a sniffer. this requires an extra machine (and perhaps a second machine more for analyzing the collected data) and perhaps changes in the network layout. There is no software package to do this. -problem: bandwidth management Bandwidth management on an ip + service based environment is possible and not tooooo complicated. For the http part, there are some packages for apache, but they have not all features needed and you cannot manage badwith for other services than http. -problem: moving vhosts DNS is not fast enough, the possible solution with a redirect to a new www2-host doesnt work in all cases. So i think it is not possible to use only one ip per machine and doing only name based hosting. I think our way with one IP per customer (NOT per vhost) is an acceptable compromise. I won't be at the RIPE-Meeting. Could someone please point out a summary of our discussion? Greetings from Germany Henning Brauer Hostmaster BSWS ------------------------------------------------ BS Web Services Roedingsmarkt 14 20459 Hamburg Germany info(a)bsmail.de www.bsws.de fon: +49 40 3750357-0 fax: +49 40 3750357-5

3 2

Re: IP assignment for virtual webhosting
by henning.brauer＠bsmail.de 11 May '00

11 May '00

There was a solution for this on this list a few days ago... How to move a hostname based virtual webserver: I have to webservers A and B (10.0.0.1) and (10.0.0.2) and want to move site www.cust.com from A to B The config on A is at the moment <VirtualHost 10.0.0.1> ServerName www.cust.com DocumentRoot ... </VirtualHost> Now move the data to B, change the nameserver entry for www.cust.com to point to 10.0.0.2 and create a www2.cust.com also to point to 10.0.0.2. The config file on B becomes <VirtualHost 10.0.0.2> ServerName www.cust.com ServerAlias www2.cust.com DocumentRoot ... </VirtualHost> and the config on A becomes <VirtualHost 10.0.0.1> ServerName www.cust.com Redirect / http://www2.cust.com/ </VirtualHost> So all request still coming in into A are redirected to the new name www2 (no DNS cache) and the DNS servers that are up to date go directly to B. Wait some time and remove the www2 entry from the DNS and clean up the config files. ------------------------------------------------ BS Web Services Roedingsmarkt 14 20459 Hamburg Germany info(a)bsmail.de www.bsws.de fon: +49 40 3750357-0 fax: +49 40 3750357-5 PLEASE USE EMAIL WHERE POSSIBLE Daniel Roesen <noc@entire-sy To: lir-wg(a)ripe.net stems.com> cc: Sent by: Subject: Re: IP assignment for virtual webhosting owner-lir-wg@r ipe.net 11.05.00 16:27 On Thu, May 11, 2000 at 04:09:45PM +0200, Herbert Baerten wrote: > And I agree with Daniel that accounting is a very important issue here. > Security is another one, firewalls being configured based on source and > destination IP addresses. And another (although minor) point: you loose flexibilty. Situation: you want to move a bunch of domains hosted on server A to another server B because of system load or whatever. With name-based vhosting you have to do the usual DNS changes and wait for DNS convergency (DNS cache timeouts) to start the move. With IP-based vhosting you can act in minutes. Move config over to server B, take down IP on server A, activate IP on server B and you're set. This means in the name-based vhosting case i have about a week (usual RR TTL) before being able to react on the slashdot effect in contrary to IP-based vhosting where I'm able to react in minutes. I already saw several well known sites suffering from exactly THIS problem. Especially for companies like us with very limited upstream bandwidth. Best regards, Daniel Roesen Entire Systems NOC -- Entire Systems Network Operations Center noc(a)entire-systems.com Entire Systems GmbH - Ferbachstrasse 12 - 56203 Hoehr-Grenzhausen, Germany InterNIC-Handle: ES1238-ORG RIPE-Handle: ESN10-RIPE Tel: +49 2624 9550-55 GnuPG/PGP Key-ID: 0xBF3C40C9 http://www.entire-systems.com/noc/noc-key.asc GnuPG/PGP Fingerprint: 1F3F B675 1A38 D87C EB3C 6090 C6B9 DF48 BF3C 40C9

3 3

Re: IP assignment for virtual webhosting
by henning.brauer＠bsmail.de 11 May '00

11 May '00

Mike, this was a bit misunderstandable as i wrote a few hours ago. traffic management is most important for different services than for different vservers. our "add an module..." requires a) to write such a module (i do not have the time and the knowledge to do so) and b) doesn't solve the problems pointed out here before (ip paket sizes for expample). if you could have a look to our server farm you would see that the "adding hardware" aproach is not our way. ------------------------------------------------ BS Web Services Roedingsmarkt 14 20459 Hamburg Germany info(a)bsmail.de www.bsws.de fon: +49 40 3750357-0 fax: +49 40 3750357-5 PLEASE USE EMAIL WHERE POSSIBLE Miquel van Smoorenburg To: henning.brauer(a)bsmail.de <miquels@cist cc: "lir-wg(a)ripe.net" <lir-wg(a)ripe.net> ron.nl> Subject: Re: IP assignment for virtual webhosting 11.05.00 17:04 According to henning.brauer(a)bsmail.de: > Yes, that exactly the way we do it. If I imagine the power needed to > implement this its nearly impossible to reimpleent for ONLY name-based > Virtual Hosts. Add an apache log module that measures the actual bytes sent out (file size + HTTP headers) - accounting problem solved. > And if you think of Bandwith management - i don't see any > way to do this on an per name-basis, only per ip (and service) is possible > as far as I know. To use Bandwidth mangement on named vhosts-basis, you > would have to read out the FULL ip-header and service-specific headers on > the router...i think this is not possible without enormous CPU-power and > would give high delays on the router. Use the Apache module mod_bandwidth, or something similar. People tend to buy and install enormous amounts of hardware, solving problems by adding more boxes. While fixing the software is simpler, easier and faster. Mike.

1 0

Re: IP assignment for virtual webhosting
by henning.brauer＠bsmail.de 11 May '00

11 May '00

Yes, that exactly the way we do it. If I imagine the power needed to implement this its nearly impossible to reimpleent for ONLY name-based Virtual Hosts. And if you think of Bandwith management - i don't see any way to do this on an per name-basis, only per ip (and service) is possible as far as I know. To use Bandwidth mangement on named vhosts-basis, you would have to read out the FULL ip-header and service-specific headers on the router...i think this is not possible without enormous CPU-power and would give high delays on the router. ------------------------------------------------ BS Web Services Roedingsmarkt 14 20459 Hamburg Germany info(a)bsmail.de www.bsws.de fon: +49 40 3750357-0 fax: +49 40 3750357-5 PLEASE USE EMAIL WHERE POSSIBLE Mark Lastdrager To: henning.brauer(a)bsmail.de <mark(a)pine.nl cc: Daniel Roesen <noc(a)entire-systems.com>, "lir-wg(a)ripe.net" <lir-wg(a)ripe.net> > Subject: Re: IP assignment for virtual webhosting 11.05.00 13:22 At Thu, 11 May 2000, owner-lir-wg(a)ripe.net wrote: >there is one big problem i see: If you charge your customers for traffic, >you must count the traffic, and the easiest and most reliable way to do >this is on the firewall/router. Thats the way we do and therefore we need >one IP per customer. Most customers have more than one site and for that we >are using HTTP 1.1 (NameVirtualHosts). >As long as there is no Package for apache to count the traffic !reliable! >(the traffic counted via access logs is << real traffic ) I do not see a >way to put all customers to a couple of IPs. Same over here. We have built our own database-driven system over the last years which links IP adresses to customers, measures their traffic and even has the ability to traffic-shape groups of IP adresses to a certain bandwith, like a Packeteer box can do. Input comes from the border router which has IP accounting. Ofcourse when customers want more than one hostname linked to the same virthost (but with different content) we use a name-based virthost. Because of this system it is very hard to implement name-based virtual hosting, all accounting is done on one IP adress then and we have to rethink our accounting scheme of virthosts (which takes time, costs money etc. etc.) Mark Lastdrager Pine Internet -- email: mark(a)lastdrager.nl :: ML1400-RIPE :: tel. +31-70-3111010 http://www.pine.nl :: RIPE RegID nl.pine :: fax. +31-70-3111011 PGP key ID 92BB81D1 :: Dutch security news @ http://security.nl Today's excuse: Dew on the telephone lines.

4 3

Re: IP assignment for virtual webhosting
by henning.brauer＠bsmail.de 11 May '00

11 May '00

thats our situation too. doing some changes in the scripts should do the things. ------------------------------------------------ BS Web Services Roedingsmarkt 14 20459 Hamburg Germany info(a)bsmail.de www.bsws.de fon: +49 40 3750357-0 fax: +49 40 3750357-5 PLEASE USE EMAIL WHERE POSSIBLE Daniel Roesen <noc@entire-sy To: lir-wg(a)ripe.net stems.com> cc: Sent by: Subject: Re: IP assignment for virtual webhosting owner-lir-wg@r ipe.net 11.05.00 16:51 On Thu, May 11, 2000 at 04:37:08PM +0200, henning.brauer(a)bsmail.de wrote: > There was a solution for this on this list a few days ago... Sure, but you're screwed if you you auto-generate your zonefiles and VHost-configs from databases and you want to move many VHosts... Best regards, Daniel Roesen Entire Systems NOC -- Entire Systems Network Operations Center noc(a)entire-systems.com Entire Systems GmbH - Ferbachstrasse 12 - 56203 Hoehr-Grenzhausen, Germany InterNIC-Handle: ES1238-ORG RIPE-Handle: ESN10-RIPE Tel: +49 2624 9550-55 GnuPG/PGP Key-ID: 0xBF3C40C9 http://www.entire-systems.com/noc/noc-key.asc GnuPG/PGP Fingerprint: 1F3F B675 1A38 D87C EB3C 6090 C6B9 DF48 BF3C 40C9

1 0

Re: IP assignment for virtual webhosting
by henning.brauer＠bsmail.de 11 May '00

11 May '00

Hi Javier, why do you use an own POP3 and FTP for each customer/domain???? We are using the same POP3/FTP/SMTP for all customers. Of course you need individual Logins, you can solve this by naming them CUSTOMERNR-1, -2 and so on or by using DOMAINNAME-1, DOMAINNAME--2 and so on. For ftp, we do a CHROOT in the customers Webroot (=his home-dir). So where is the problem?? Henning Brauer Hostmaster BSWS ------------------------------------------------ BS Web Services Roedingsmarkt 14 20459 Hamburg Germany info(a)bsmail.de www.bsws.de fon: +49 40 3750357-0 fax: +49 40 3750357-5 PLEASE USE EMAIL WHERE POSSIBLE "Javier Llopis" To: "lir-wg(a)ripe.net" <lir-wg(a)ripe.net> <javier@bitma cc: iler.com> Subject: Re: IP assignment for virtual webhosting Sent by: owner-lir-wg@ ripe.net 11.05.00 13:41 Please respond to "Javier Llopis" On Mon, 08 May 2000 18:26:19 +0200, Nurani Nimpuno wrote: >We do however wish to raise our concern regarding what we see as an >inefficient usage of addresses in our limited address pool. We would >therefore like to request the community to consider making it >mandatory for NEW installations to use domain based web-hosting, with >the exception of a set of agreed applications needing IP based >web-hosting (eg. SSL). There is one issue I'd like to bring up that we constantly run into and was never brought up in this debate, which somehow amazes me. Our typical situation is that when a customer orders a domain named web site it comes along with an FTP server and a POP-3 server so they can have their own email addresses. While we could host all customer pages on the same host with the same IP using HTTP 1.1, in order to do the same with the POP servers we need to distinguish the POP server by its single IP address, since there is no HTTP 1.1 equivalent for POP. So we end up with 99% of our domains having a different IP address each, in which case who _cares_ if we also use that IP address for the web server? Are we really wasting IP address space? Hasn't anybody run into this situation? If so, how are you dealing with it? We would ask that, unless a viable solution to this problem is found, name based hosting should be encouraged but not required. BTW we are adopting HTTP 1.1 name based virtual hosts anyway in case the FTP and POP issues could be solved. Regards Javier Llopis BitMailer, S.L. javier(a)bitmailer.com Juan Bravo 51, Dup. 1-Izq Tel: +34 91 402 1551 28006 Madrid Fax: +34 91 402 4115 SPAIN

3 3

Re: IP assignment for virtual webhosting
by henning.brauer＠bsmail.de 11 May '00

11 May '00

I have written about accounting, but no one replied! once again: Hi all, there is one big problem i see: If you charge your customers for traffic, you must count the traffic, and the easiest and most reliable way to do this is on the firewall/router. Thats the way we do and therefore we need one IP per customer. Most customers have more than one site and for that we are using HTTP 1.1 (NameVirtualHosts). As long as there is no Package for apache to count the traffic !reliable! (the traffic counted via access logs is << real traffic ) I do not see a way to put all customers to a couple of IPs. Greetings from Germany Henning Brauer Hostmaster BSWS ------------------------------------------------ BS Web Services Roedingsmarkt 14 20459 Hamburg Germany info(a)bsmail.de www.bsws.de fon: +49 40 3750357-0 fax: +49 40 3750357-5 PLEASE USE EMAIL WHERE POSSIBLE Daniel Roesen <noc@entire-sy To: "lir-wg(a)ripe.net" <lir-wg(a)ripe.net> stems.com> cc: Sent by: Subject: Re: IP assignment for virtual webhosting owner-lir-wg@r ipe.net 11.05.00 12:31 On Thu, May 11, 2000 at 11:41:58AM +0000, Javier Llopis wrote: > There is one issue I'd like to bring up that we constantly run into > and was never brought up in this debate, which somehow amazes me. And another one, not raised (enough): Accounting Best regards, Daniel -- Entire Systems Network Operations Center noc(a)entire-systems.com Entire Systems GmbH - Ferbachstrasse 12 - 56203 Hoehr-Grenzhausen, Germany InterNIC-Handle: ES1238-ORG RIPE-Handle: ESN10-RIPE Tel: +49 2624 9550-55 GnuPG/PGP Key-ID: 0xBF3C40C9 http://www.entire-systems.com/noc/noc-key.asc GnuPG/PGP Fingerprint: 1F3F B675 1A38 D87C EB3C 6090 C6B9 DF48 BF3C 40C9

6 7

Re: IP assignment for virtual webhosting
by Javier Llopis 11 May '00

11 May '00

On Thu, 11 May 2000 12:25:55 +0200 (CEST), Nils Jeppe wrote: >> Mmmm... A customer having two addresses in two different files/databases: >> That works but might be a nightmare to update. > >Nah, not really... it's still better than having to ervice/update/maintain >dozens of independent mail servers. But we DO have only one big POP server, the only thing is that it looks the IP address the client is connecting to to know which domain she belongs to. The alias approach is workable, but I foresee update inconsistencies created over time which can be a pain in the neck. But even then I'd have go to hundreds of organizations and thousands of users to tell them to reconfigure their email programs in a way that they won't understand (believe me). And I would have to tell them that in order to use the handy web-mail gateway they have to type an awkard user name, instead of 'my address is someuser(a)somecompany.es' I can put up with the update problem since that is an internal matter of my organization, but I don't want this kind of things to reflect outside nor I want customers to change their simple way of doing things if not for the better (for them, not for us or RIPE). Javier Llopis BitMailer, S.L. javier(a)bitmailer.com Juan Bravo 51, Dup. 1-Izq Tel: +34 91 402 1551 28006 Madrid Fax: +34 91 402 4115 SPAIN

1 0