Personal Internet Access Using SLIP or PPP: How You Use It, How It Works Frank Hecker hecker@access.digex.net May 6, 1994 Copyright 1994 by Frank Hecker. You may redistribute this document freely in any form provided only that you retain this copyright notice. This document is available online via anonymous FTP from: ftp.digex.net:/pub/access/hecker/civic-nets/personal-internet.txt Introduction As the Internet has been popularized in newspapers, magazines, and books, many people are joining (or trying to join) the community of Internet users online. Some subscribe to commercial services like CompuServe and America Online that are adding some Internet-related features to their existing services. Others purchase accounts on commercial services which provide Internet access as their main offering, or are getting accounts on "Free-Nets" and other community network systems which offer Internet access as an adjunct to community information. Finally, there is a small but rapidly growing number of people who are experiencing the joys of connecting to the Internet directly from their PCs or Macintoshes, without having to log in to larger systems and put up with the hassle of UNIX commands or restrictive menus. In this paper I discuss this highest level of personal Internet access: both how you use it and how it works. I assume that you have some understanding of the Internet and what services it supports (e.g., Telnet, FTP, and electronic mail), but that you know very little about TCP/IP, SLIP, PPP, and other obscure acronyms. This document was originally written for the Washington, D.C., area community network CapAccess (the informal name for, and a service mark of, the National Capital Area Public Access Network, Inc.). I'd like to thank the other members of the CapAccess organization for their comments on early versions of it. However the views I express herein are mine alone and do not necessarily reflect the official position of CapAccess. Me, My Mac, and the Internet When I first became an Internet user, I used a so-called "shell account" provided by a local D.C.-area Internet access provider, the Digital Express Group, Inc. (It's called a shell account because you login to a central UNIX host and type UNIX commands into the UNIX command interpreter, or shell.) I used this service much like you might use a BBS, a "Free-Net," or other UNIX-based community network systems like CapAccess (albeit with a few more functions): I would use my Macintosh and its modem to login to the central UNIX host (a Sun system), read and compose electronic mail using Pine (a UNIX email program, read and post USENET news articles using a UNIX-based newsreader, retrieve files using FTP and download them using Zmodem, and so on. For software I used the shareware communications program Zterm, a copy of which came with the Global Village 14.4 kbps modem I have. (For those of you who have PCs, Zterm is a typical character-based communications program with VT100 terminal emulation and download capabilities, comparable to Procomm or CrossTalk.) Recently I took the plunge and upgraded to a so-called "SLIP account." SLIP or Serial Line Internet Protocol is a communications protocol that supports an Internet connection (i.e., using TCP/IP) over a dial-up line. PPP or Point-to-Point Protocol is a newer protocol that does essentially the same thing; it's just more elegant to the kind of people who like to read protocol specifications. For the rest of us it's six of one and a half dozen of the other for the most part, and I'll often use the term "SLIP/PPP" to refer to them interchangeably. Not only was setting this up much simpler than I anticipated, it also gave me a whole new perspective on how individuals will likely use the Internet in the future. I'll get to the technical details later, but I'd like to start by describing a typical communications session: I start with my Mac booted and its modem connected to a phone line. First, I invoke the SLIP application. (In Mac terms this "application" actually consists of an extension plus control panel, roughly comparable to a TSR utility in DOS terms). It asks me for my SLIP password (which goes with my SLIP userid--more on this below), and then uses a script to dial the SLIP access number at my Internet access provider. My modem dials out, their modem answers, and then the script takes over for a few seconds until the SLIP connection is established. I then forget about the SLIP application, and often close it just to get it out of the way. (Part of it is still running "underneath," of course.) At this point I have a live connection between my Mac and the Internet. The next thing I typically do is start up the Eudora mail program, and then ask it to check for and retrieve my electronic mail. Eudora asks for my mail account password (which goes with my mail account userid). Note that these are a different userid and password than my SLIP userid and password; I discuss this in more detail below. Eudora then goes out and downloads my mail from my mailbox on the Internet access provider's mail server. This can take from a few seconds to a few minutes, depending on how much mail I've received and how big the messages are. When downloading completes I have all my new mail messages in an inbox on the Mac. I can then either read my mail or do something else. Typically I read at least a few messages that look important, and perhaps respond to a couple of them. When I respond, my messages get put in an outbox for later delivery; they aren't sent right away. Suppose one of the messages is about something on another Internet- connected system, such as the CapAccess community network system. I then invoke the NCSA Telnet application and connect to CapAccess ("cap.gwu.edu") to check things out. This brings up a VT100-like screen similar to what you'd get dialing in directly, with the prompt for the login id. I give my CapAccess userid and password, and then I'm logged in as usual and can do all the standard CapAccess operations. Note that this Telnet connection isn't going through either the Internet access provider's UNIX host system or the CapAccess terminal servers (which support the modems); it's going over the Internet from my Mac to the CapAccess Sun system (with some hops through Internet routers along the way, of course). Suppose that something I read in a CapAccess forum refers to an information file that you can FTP from someplace. Then, _without closing the Telnet session_, I can bring up the Fetch application, which is an implementation of FTP for the Mac. Fetch allows me to start a session to a public or "anonymous" FTP site, browse through the directories, and download files using FTP direct to my Mac; download speeds for text and binary files are comparable to those achievable using traditional communications programs and protocols like Zmodem. (They are not quite as fast, for various reasons too complicated to go into in this paper, but they are fast enough for me.) After finishing the FTP session I can go back to my Telnet session and continue. TCP/IP and SLIP (or PPP) can "multiplex" several connections; that is, several connections can be open at once and can be sending and receiving data, with TCP/IP and SLIP/PPP sorting it all out and transmitting and receiving that data over the single dialup connection to the Internet acces provider's SLIP/PPP access point. If the Mac had true "preemptive" multitasking (like OS/2 or Windows NT, for example), I could actually have different downloads going on simultaneously while I ran other Internet applications. As it is though, doing an FTP transfer will pretty much kill performance on a Telnet session; however it works fine to keep multiple applications open for use but otherwise idle, and I can then switch between them. If I'm really done with my Telnet session, I'll log out of the remote system and close the link. I might then bring up NewsWatcher, a USENET news reader for the Mac. NewsWatcher connects to the Internet access provider's USENET news servers and then presents me with a list of my currently subscribed newsgroups, together with an indication of how many postings are available in each group. I double-click on a newsgroup I'm interested in checking, and Newswatcher downloads the list of current postings in the group, by subject. (It knows about message threads, so if multiple postings have the same subject it only shows me one line in the listing of articles.) I then double-click on the line corresponding to a posting (or thread) I want to read, and Newswatcher downloads the text of that posting and puts it on the screen in a window. More double-clicking lets me advance through the newsgroup article by article, marking articles as having been read as I download and read them. I can also compose and post followup articles or new articles, which are uploaded to the USENET news server. If I don't read all articles in a newsgroup or get through all newsgroups, I can look at them later when I next use NewsWatcher. I can also mark articles as having been read without downloading them, in case the subject line indicates that I would have no interest in them. Thus far in this example I've discussed electronic mail (Eudora), Telnet (NCSA Telnet), FTP (Fetch), and USENET News (NewsWatcher). I also have TurboGopher, a Macintosh version of a Gopher client. TurboGopher allows me to get exactly the same information accessible via a so-called "VT100" Gopher client (as found on many Internet hosts), but with the following advantages: it gives me a point and click graphical interface; files can be saved directly to my Mac (as opposed to saving them in a host UNIX directory and then downloading them); and it doesn't require me to login to to a UNIX host first. Finally, I have the much-heralded NCSA Mosaic (the Macintosh version, of course), and can explore the World Wide Web with full access to multimedia information including formatted text, graphics, sound, etc. I must confess that using Mosaic over a 14.4 kbps dialup line is not nearly as exciting as the hype would suggest. Mosaic typically takes a minute or more just to bring up a single page of information, because of all the embedded graphics included in most WWW data. (You can turn off downloading the graphics images, but then what's the point?) I accessed a sound clip once; it took about five minutes of downloading just to hear my Mac talk to me for a few seconds. But it's still fun to play with, and there are many new information sources that can be accessed only through the World Wide Web and a WWW client program like Mosaic. Of course while all this is happening TCP/IP and SLIP are running quietly underneath it all over the dialup link. After a while I figure it's time to save my pennies and cut the connection. (I get four "free" hours per day--i.e., included in my basic monthly rate--but this can go fast, especially as I connect at least two or three times a day.) I remember I still have electronic mail messages in my Eudora outbox, so I go into Eudora and tell it to send all outgoing mail. It uploads the messages to my Internet access provider's mail server, which then will take care of sending them on to their final destination. Having finished all my online stuff, I go back to the SLIP application and tell it to disconnect. At that point I lose all the fancy functionality like Mosaic, FTP, etc. However I can still read my electronic mail in Eudora, compose replies, and queue them for delivery the next time I connect. In summary: * I have dialup Internet access using a special dialup number and a userid and password associated with that access. * I can run a wide variety of applications over the dialup link to implement traditional Internet services such as electronic mail, FTP, Telnet, and USENET news, as well as newer services like Gopher and Mosaic/WWW. * Using some Internet services (e.g., electronic mail) requires that I have additional userids and passwords assigned to me by my Internet access provider. Others do not; that is, they are either inherently anonymous in nature (e.g., anonymous FTP, Gopher, Mosaic/WWW) or involve separate arrangements with other organizations (e.g., Telnet to a remote Internet host like CapAccess). * Most of these services can only be used while the dial-up Internet connection is active. However with others (really only electronic mail, for now) you can do at least some things off-line. (There's no reason in theory why some of the USENET news reading process can't be done offline; however the current version of the NewsWatcher application does not implement this.) How It All Works Having told you how I access the Internet from my Mac, I'd like to now go into more detail about what's going on behind the scenes. My apologies for the level of technical detail; I'll try and keep it to the minimum necessary to make my points. (Although I can't resist running with a good extended analogy, as you'll see.) Let's start with what "being on the Internet" really means. For your PC or Macintosh to be "on the Internet" in the sense that I'm using the term, the following three things must be true: * Your PC or Mac has software which can send and receive data using the TCP/IP family of communications protocols. * Your PC or Mac has some sort of communications link to an Internet access point from which data it sends can go out over the Internet to other systems, and by which data sent from other systems on the Internet can be sent to your PC or Mac. * When connected in this way, your PC or Mac has an identifying number (called an "IP address") which other systems use in sending data to your PC or Mac, and by which your PC or Mac identifies itself when sending data to other systems. For those who really want to know, "TCP/IP" stands for Transport Control Protocol/Internet Protocol (which are really two separate protocols), and is a shorthand name for a specific way of packaging up data for sending it over a comunications link. TCP/IP is analogous in many ways to protocols like Kermit or Zmodem which package up data for downloading or uploading over "normal" dial-up connections (e.g., to a BBS). But you really don't need to know that, any more than you need to understand how telephone line signalling works in order to call someone. In fact, this is a good analogy if you think about what it means to be "on the public telephone network" and use local or long-distance phone service: * You have a device (i.e., a telephone) which can send and receive data (i.e., the sound of voices) using some sort of low-level magic (which you don't really worry about). * Your phone has a communications link (phone line) to an access point (your local telephone central office) through which your phone can connect to other phones anywhere in the world (and vice versa). * When connected in this way, your phone has an identifying number (your phone number) which other phones use in connecting to your phone, and by which your phone is identified when connecting to other phones (as in Caller ID). The three elements common to both cases are thus as follows: * you have an end-user device which has the smarts to "talk" in a certain way; * you have a link to an access provider over which your device can "talk" with other devices; and * your devive has an identifying number or address used when your device "talks" to other devices and vice versa. If it's that simple, why has connecting to the Internet traditionally been so hard for individual users? Because doing it has been like trying to get phone service in an environment where you have to build your own phone, you have to search far and wide to find a phone company (and may not have one at all in your area), and you have to pay a big premium for service if and when you find a service provider. Making Your Mac or PC Internet-Capable ("Building a Phone") Let's go back and analyze what's happening when I use my Mac on the Internet. First, let's discuss what you need to make your PC or Mac Internet-capable, "building a phone" as it were (and we'll price it out to boot). I start with a Macintosh system with a 14.4 kbps modem. Assuming that you already have a PC or Mac, a new 14.4 kbps modem can be had for as little as $100 to $150 or so, depending on the modem's brand, whether the modem is external or internal, and so on. To that I add the requisite TCP/IP software. For Macintoshes this comes in two parts: First comes a product called MacTCP supplied by Apple; MacTCP is the standard TCP/IP product for all Macs. Then comes software to implement either the SLIP or PPP protocols that MacTCP needs to support TCP/IP over dialup links. I use the InterSLIP software from Intercon Systems Corporation; InterSLIP is freeware. MacTCP is not freeware, but you can get it (along with InterSLIP and related stuff noted below) by buying the book _The Internet Starter Kit for Macintosh_ by Adam Engst (Hayden Books, $29.95) or similar volumes from other publishers. Also, Apple will be including MacTCP in the upcoming System 7.5 operating system (to be released later this year). After its release System 7.5 will be shipped with new Macs, so at that point you'll be able to get TCP/IP software on new Macs at no extra cost whatsoever. (You'll be able to get it for old Macs by buying System 7.5 separately.) For 386 or better PCs running Windows 3.1 you can get a similar combination of TCP/IP software with SLIP capability by buying the book _The Internet Unleashed_ (SAMS Publishing, $44.95) or similar works. The software in this case is a entry-level version of Chameleon from NetManage. In the next major release of Windows (Windows 4.0 or "Chicago") Microsoft will be including TCP/IP and PPP capability in the base operating system at no extra cost to users who receive Windows 4.0 preloaded on their system or buy it as an upgrade. I should add that the cheapness of TCP/IP software for Macs and PCs is a very recent phenomenon. Traditionally TCP/IP software has been seen as of interest only to businesses running LANs, and it cost up to around $400 or $500 per PC or Mac. This is still true if you need true LAN capabilities, but software vendors have woken up to the rapidly growing market for individual use of TCP/IP over dial-up lines to access the Internet. Thus the drop in price to less than $50, at least for basic capabilities. As noted above, within the next year or so this cost will drop further to zero; that is, at some point TCP/IP and SLIP or PPP capability will be bundled with the base operating system software shipped with every new Windows PC and Mac. At that point the only incremental cost to make your PC or Mac "Internet-capable" will be for the modem itself, which many if not most people who buy computers will be buying anyway for other reasons. Connecting to the Internet (Getting "Internet Dial Tone") I've now "built a phone" and have the proper TCP/IP and SLIP software installed on my modem-equipped Macintosh (or PC, as the case may be). Next I sign up with a service provider that can give me a connection to the Internet (in my case the D.C.-area company Digital Express Group, Inc.). My Internet access provider supplies me with at least three things (actually more, but we'll get to that): a dial-up SLIP access phone number to have my modem connect to, a personal "SLIP userid," and a personal password to go with the SLIP userid. The SLIP userid is some arbitrary string like "xx537", and the password is like a standard login password for a UNIX system or BBS. I configure the InterSLIP software with the dial-up SLIP access phone number and my SLIP userid, and then direct the software to call up the SLIP phone number using the Mac's 14.4 Kbps modem. The call is answered by a corresponding 14.4 Kbps modem at the other end (like the ones used by BBSs). The modem at the other end is connected to a SLIP-capable "terminal server," basically a black box that will end up taking the data coming from my Mac over the dial-up line and retransmitting it to my Internet access provider's LAN, which is in turn connected to the Internet using an "IP router" (another black box you don't have to worry about). This terminal server is similar to the ones used at many Free-Nets and other community networks like CapAccess to connect users from dial-up modems over a LAN into the actual UNIX host system they login to. The main difference is that the SLIP-capable terminal servers at the Internet access provider have an extra capability which lets them pass TCP/IP data through. (Access using PPP is almost identical.) In fact, when you first connect to the Internet access provider's modem and terminal server, it looks very much like logging in to a remote UNIX system. (That's if you were looking at the conversation, which typically you don't--login is normally handled by an automated script). The first thing you would see is a prompt for a userid, at which point you (or the script) enter the special SLIP/PPP userid. You would then see a password prompt, in response to which you (or the script) enter the SLIP/PPP password. (The SLIP or PPP software would prompt you for your password if you hadn't supplied it with the rest of your configuration information.) On a BBS or UNIX system you'd next see the opening screen and menu (or UNIX prompt). However with a SLIP or PPP connection your software and the terminal server now go into a special mode where they start exchanging TCP/IP data. This is somewhat reminiscent of what happens when a communications program is in download or upload mode, and if you looked at what's actually going across the dial-up line it would look pretty much like garbage with a few recognizable bits mixed in. However you don't actually see the garbage because the SLIP or PPP software doesn't bother showing it to you; it just says "connected" and that's it. A couple of important things to note: First, having made the SLIP or PPP "connection" you really aren't logged in to any host; you just have the capability to send data out over the Internet. To continue with our telephone analogy, you've plugged in your "phone" and have "Internet dial tone" but you haven't called anybody yet. You might ask, why do you need a userid and password if you're not actually logging in to anything? Because my Internet access provider wants to be able to bill me for the time I spend connected to the Internet through their terminal server, and to do this they need an id of some sort to know it's me connecting. I in turn would like a password so that no one else can connect to their SLIP/PPP terminal server and bill time to my id. You can think of this as my "Internet calling card number" and associated PIN. For those really into the bits and bytes, an interesting technical question is: How does the SLIP/PPP terminal server check my userid and password and account for my connect time? The answer is that it sends the userid and password to a real computer system to be checked against a userid/password database; for many modern terminal servers this is done using the "Kerberos" authentication protocol invented at MIT. If the SLIP/PPP userid checks out, the terminal server then sends a "start of call" record to a real computer system, to be stored in a log (many terminal servers use the UNIX "syslog" protocol for this); a similar "end of call" record is sent when the modem connection ends (i.e., the user disconnects). These two records together enable the Internet access provider to compute the time and length of the SLIP or PPP session for billing purposes. Again, this is all surprisingly similar to the way long-distance calling cards work. The analogy extends even further: if I always made the connection from the same phone, my Internet access provider could theoretically use Caller ID or similar mechanisms to know it was me calling, just as I don't have to enter a calling card number to dial long distance from my home phone. However, just as I might make long distance calls while on the road, I might connect my modem to different phones (and in fact I do, as my Mac is actually a PowerBook laptop); thus having a SLIP/PPP userid and password is necessary to handle this. There's another crucial piece I've left out so far: my "Internet phone number," the IP address. My Internet access provider assigns me my very own IP address (mine is 164.109.211.201, in case you're curious); this is the fourth piece of initial information I was given when I signed up, along with the three I've already mentioned: SLIP/PPP dial-up access number, SLIP/PPP userid, and SLIP/PPP password. Many terminal servers also have the ability to assign callers an IP address "on the fly;" the address picked is displayed during the login sequence and the TCP/IP software on your PC or Mac then picks it up and uses it. When you dial up the next time, you might get a different IP address. This is not as confusing as you might think, as it turns out that for various reasons (touched on later) it really doesn't matter what your IP address is, as long as you have a connection. The theory behind doing this dynamic assignment of IP addresses is that it lets the Internet access provider use a limited size pool of addresses to serve a much larger number of people. After all, people only need the address when they're connected to the modems and SLIP/PPP terminal server, so the Internet access provider really doesn't need to supply any more IP addresses than it has dial-up SLIP/PPP ports. However I prefer the way my Internet access provider does it. For one thing, it's much easier to understand, especially using the phone number analogy. For another, the IP address is often used by remote systems to identify who's connecting to them over the Internet, just as people use Caller ID to identify who's phoning them. (Using the IP address for authentication in this way is not totally secure and fool-proof, but then neither is Caller ID for that matter.) With "on the fly" assignment I might get a given IP address at one point, and someone else could get the same address a few minutes later after I disconnect from the service. To summarize: after signing up with an Internet access provider and connecting to their SLIP/PPP terminal server we're now "on the Internet" (or we have "Internet dial tone" if you will), having fulfilled the three conditions we discussed above: * With the help of a modem and low-cost TCP/IP software we have an "Internet-capable" PC or Macintosh. * We've established a TCP/IP over SLIP (or PPP) connection to our Internet access point. * We've got an IP address or "Internet phone number" and are ready to "make calls;" i.e., to connect to other systems and make use of Internet services. This has been a long section and we still haven't gotten to the point of doing anything really useful. But have patience; believe me, even telephone dial-tone would seem this complicated if you really looked "under the covers." In fact, just a few years ago (before "equal access") getting long-distance phone service through a non-AT&T carrier such as MCI was pretty complicated, even for the casual user; some may remember when you had to first dial a special MCI access number and enter your personal MCI access code before you could dial a long-distance number. Use Core Internet Services ("Making Some Calls") At the end of the last section I'd gotten to the point where my Macintosh had "Internet dial tone:" it had established a TCP/IP link to the SLIP/PPP terminal server of my Internet access provider, and was now ready for me to do useful work (or "make some calls," to continue our telephone analogy). The first thing I did in my example was to check my electronic mail, and so I started the Eudora mail program. Eudora is available for both Macs and PCs running Windows. In its first incarnation (release 1.4) it was a freeware program; I got my copy from the _Internet Starter Kit_ book. Eudora is now also available in a commercial version (release 2.0) with somewhat more functionality (like mail filters) and technical support; I recently bought a copy of release 2.0 for $65 from QUALCOMM, the vendor that now sells and supports it. However, before I explain how Eudora works, I have to digress for a moment and talk about Internet electronic mail. Traditionally Internet users have logged in to multi-user systems which were connected to the Internet 24 hours a day. When users send mail (say from "jdoe@cap.gwu.edu" to "rroe@anytown.gov") the messages are transmitted (almost) immediately over the Internet from the originating host ("cap.gwu.edu") to the receiving host ("anytown.gov") and then are put in the mailbox for the recipient ("rroe"). (Incidentally, the low-level protocol used to send messages between electronic mail hosts is called SMTP, for Simple Mail Transfer Protocol.) At some later time the recipient ("rroe") logs into the receiving mail host and then reads the mail messages out of their mailbox using a mail reader such as Pine or Elm. They can then compose new messages, which are then sent to the recipient's mail host as described above. Note that the user has to stay logged in to their mail host during the entire time they're reading messages and composing new ones. The method is the way I used to read and compose mail using my original Internet shell account: I would login to my Internet access provider's host system ("access.digex.net") and use Pine. However, now that I have a Macintosh which can be linked to the Internet more directly, I would much prefer to read and compose mail on the Mac itself and send it or receive it over the Mac's Internet connection. Well, my Mac does have its own Internet address ("164.109.211.201") and even its own Internet hostname ("ion.digex.net"). (I'll discuss how Internet hostnames work in more detail below when I talk about FTP.) Unfortunately, though, I can't use the traditional SMTP mail protocol, at least to receive mail. Why? Because mail sent using SMTP is sent directly to the recipient host, which in this case would be my Macintosh ("ion.digex.net"), and my Mac would have to be on the Internet to receive it; otherwise the sending host would not be able to make an SMTP connection. But because I'm using an intermittent dial-up SLIP/PPP connection, there's no guarantee that my Mac would be online at the exact time the sending host wanted to send the message, and thus I would end up never receiving messages sent to me. Going back to our telephone example, sending Internet electronic mail in the traditional manner (i.e., using SMTP end-to-end) is somewhat like leaving a message for someone on their personal answering machine: you can call their phone number 24 hours a day, and their answering machine is always turned on and ready to record messages. But in my case my "Internet phone number" (IP address) is only active part of time (when I'm connected to my Internet access provider via SLIP or PPP and have "Internet dial tone") and my "personal answering machine" (my Mac) won't always be turned on and ready to receive my messages. The solution to this problem is very simple: I'll have another Internet system (a "mail server") receive my email messages for me, and then when I'm connected to the Internet I'll download my mail messages from that system to my Mac. Continuing the answering machine analogy, this arrangement is similar to what phone companies provide via services like Bell Atlantic's AnswerCall; in place of your having your own answering machine, the phone company provides a voice mailbox for you somewhere in their network, and callers to your number can leave messages in that voice mailbox. You can then periodically call a special phone number associated with the voice mailbox service, punch in your access code, and listen to your messages. In my case, rather then sending email to "hecker@ion.digex.net" (recall that "ion.digex.net" is the hostname of my Macintosh), people send email to "hecker@access.digex.net", where "access.digex.net" is the name of the mail server run by my Internet access provider; this system runs 24 hours a day and has a permanent Internet connection. Once my Internet SLIP connection is active, I then have Eudora connect to the host "access.digex.net" over the Internet and download any messages I've received since last I connected. (The specific protocol used to do this is _not_ SMTP, but is another protocol called Post Office Protocol or POP. In particular Eudora and the "access" system use POP3, the third and most recent version of this protocol. In technical jargon the system "access.digex.net" is thus a POP3 mail server.) I didn't mention it above, but I also have to supply Eudora with a userid and password, which it then passes on to the mail server when connecting to it using POP. If there were no userid or password, then anyone else on the Internet could connect to my Internet access provider's mail server and download my mail. As it happens, my "mail userid" and associated password are the same ones I used to use when logging in to the "access" system itself as a user of an Internet shell account, namely "hecker" and the corresponding login password. This makes for a smooth transition from the old way of doing things (using a shell account) to the new way (using SLIP/PPP): my electronic mail address is still "hecker@access.digex.net" (userid "hecker" on host "access.digex.net") and I don't have to choose a new password if I don't want to. Also, if I ever want or need to I can still dial up the "access.digex.net" system in the old way (i.e., using a VT100-compatible communications program instead of SLIP or PPP) and login and read my mail using Pine. (The mailbox format used by POP is the same standard UNIX mailbox format used by Pine, Elm, and other host-based mail programs.) However, my mail userid and password are _not_ the same as my SLIP/PPP userid and password that I've previously mentioned; this is because we are talking about two fundamentally different services provided in two fundamentally different ways. SLIP/PPP access is a low-level communications service accessed by dialing up a SLIP/PPP-capable terminal server; POP email access is a higher-level service accessed by connecting over the Internet to a POP3-capable host system (mail server). Thus if you get a new SLIP or PPP account from an Internet access provider you'll receive an email (POP) userid and password in addition to your SLIP/PPP userid and password. Suppose that I had a full-time hard-wired Internet connection in my home (for example, like those starting to be provided by some cable companies). I would then have "Internet dial tone" all the time, and I wouldn't need something like SLIP or PPP to connect. I also wouldn't need the equivalent of a SLIP/PPP userid and password; as I discussed previously, their main use is for authentication and billing for Internet access, and the cable company already has a perfectly good way to bill you for cable-based services. However I might still want the cable company to store my incoming electronic mail messages for me; for example, I might not want to keep my Macintosh turned on all the time. In this case I could use Eudora and POP to connect to a remote mail server, just as I do now over SLIP or PPP, and I would still have to have an mail userid and password supplied to me by the cable company in its role as an Internet access provider. Continuing the answering machine analogy, having an electronic mailbox accessed using POP can thus be viewed as a value-added option to a basic Internet connection, just as having a voice mailbox through Bell Atlantic's AnswerCall is a value-added option to a basic phone line. This also implies that email service could be "unbundled" from basic Internet service; for example, you might have a basic Internet connection but no electronic mail service, or (more likely) you might get basic Internet service from one service provider and an electronic mailbox service from another. (As it happens, I don't know of any Internet access provider that currently unbundles POP-based email in this way. However as competition heats up in the Internet access market, some companies may choose to further break their current services down into standard and optional offerings, in order to offer the lowest entry-level price possible. There may also be a market niche for companies providing SLIP/PPP service only, with customers expected to arrange for electronic mail service on their own; some non-profit Internet cooperatives do business this way today.) Back to Eudora: As I've mentioned, once Eudora has downloaded my incoming email messages to my Mac I can then read them at my leisure; I don't need to maintain the Internet SLIP connection. What about sending messages? Here again I don't need to be connected in order to compose messages, but I do need to be connected in order to send them. As it turns out, for historical reasons (a fancy way of saying "that's just the way it is") the POP protocol is not used when sending electronic mail messages. Instead Eudora uses the SMTP protocol I mentioned earlier, but with a twist. In "SMTP classic" the sending host (my Mac in this case) connects directly to the receiving host (say "whitehouse.gov", if I'm sending a message to Bill Clinton). However the receiving host might be down or unreachable due to some Internet problem, so that Eudora would have to postpone sending the message to a later time, say a few hours later. But why should I have to go to all the trouble of remembering to reconnect periodically to my Internet access provider? Instead what happens is that Eudora uses the SMTP protocol to send my message to my mail server. The server then uses SMTP again to send the message on to its final destination. If the mail server can't do so right away it will keep trying until it succeeds; meanwhile I can disconnect my Mac and not worry about it. You may have noticed that I didn't say anything about userids and passwords when sending mail. That's because the mail server doesn't authenticate me in any way when sending mail via SMTP; I just tell Eudora to upload the message and the email server accepts it. You might then ask, "Doesn't this mean that someone else can send fake electronic mail under your name?" For this and other reasons, the answer is yes, they sure can. As it happens, it is almost trivially easy to send forged Internet mail, and has been ever since Internet mail began. This is why, for example, you should be very skeptical if you ever get a message purportedly from your Internet access provider telling you that they need to know your userids and passwords for some reason. There are well-known ways to solve this problem, but they haven't been implemented because they depend on encryption and related technologies, and implementation in the Internet has been held hostage to the same sort of disputes as we've seen in the infamous "Clipper chip" controversy. (I don't want to rehash this whole issue, but I do want to point out the basic underlying problem. In the "market" that is the Internet, the most successful "products" are based on technology that is available worldwide and is in the public domain or otherwise freely usable. Exporting encryption technology from the U.S. is legally restricted because of national security concerns, and "public key" encryption, the most useful type for electronic mail, is covered by a software patent in the U.S. Thus there are at least two major obstacles to creating a world-wide standard for secure Internet mail. Yet another example of how once obscure policy questions often eventually come to affect all of us.) That's about it for electronic mail. The case of USENET news (online conferences) is somewhat similar, and worth covering at this point. Again, we need to digress for a moment and talk about how USENET news works underneath. USENET is not a communications network per se but rather a loosely-organized collection of host systems which exchange conference articles with each other. (In this sense USENET is analogous to FidoNet in the PC BBS world, and in fact there are gateways between USENET and FidoNet.) When a conference article is submitted (or "posted") on one system it is then sent on to one or more other systems, which then send it on to others, and so on (rather like a chain letter), until all USENET hosts receive it. Once an article is received at a host it is stored for people to read it. There are a few thousand USENET conferences (or "newsgroups") and several thousand USENET hosts around the world. Thus as you might imagine a lot of traffic flows through the system every day, so much so that a USENET host system typically stores only the last few days worth of articles. If I want USENET access from my Macintosh I thus have at least three possible ways to get it. First, I could have my Mac be a full-fledged USENET host and receive all conferences; this is pretty much out of the question, given that it's hard to fit several gigabytes of disk space in a PowerBook. Second, I could have my Mac be a USENET host but receive only a few newsgroups; this is a much more reasonable thing to do, and you can get software on the Mac to do it, but you'd still be receiving every article in every newsgroup you chose, even articles of little or no interest to you. The third alternative is what I use with my Mac and NewsWatcher: connect to a remote Internet host acting as a "news server;" this host ("news1.digex.net" in my case) receives all USENET newsgroups and stores all articles for as long as it can without running out of disk space. Assuming that I have an Internet SLIP/PPP connection active, I then have NewsWatcher connect to the news server over the Internet and download the list of articles (i.e., by subject line) in each newsgroup. I then pick which articles I want to read and have NewsWatcher download only those articles; the rest are left on the news server. Conceptually this process is quite similar to using a POP mail server as described above. As with mail there is a special protocol, NNTP (Network News Transfer Protocol), which NewsWatcher and the news server use to talk to each other. However I don't have to supply a userid or password when reading and posting news. I do have to tell NewsWatcher my email address ("hecker@access.digex.net") because this is used to mark my posted articles as coming from me, and is also needed when I send mail to someone in lieu of posting a reply to the newsgroup. However this information is not used to authenticate me to the news server in any way. You might ask, can anyone on the Internet then use NewsWatcher (or other NNTP client software) to read and post articles from and to my Internet access provider's news server? There are some news servers (sometimes called "public NNTP sites") on the Internet for which this is true; using these servers anyone can read or (in some cases) post USENET news articles. (And I might add, using these servers as well as through other means it is possible to send forged USENET postings under another's name, similar to what can be done with Internet mail.) However my Internet access provider's news server will not accept requests from anywhere on the Internet; it will only accept requests from IP addresses and hostnames that it knows about, that is, that represent valid subscribers to the provider's SLIP or PPP service. Since my Mac has an IP address and Internet hostname assigned by the Internet access provider when I signed up, the provider's news server will recognize me as a valid user. Thus IP address and hostname are again used as a useful (albeit not totally secure) means of authenticating users. The final point I want to make about USENET news is that, like access to an mail server, access to a news server is a value-added service over and above basic SLIP or PPP Internet access and could in theory be unbundled as well, so that you might have a basic Internet connection with no mail or USENET news service at all, an Internet connection and mail service but no USENET news service, or Internet service, mail service, and news service from one, two, or even three providers. (Again, most present-day Internet access providers do not in fact unbundle services in this manner.) Other Internet Services With both electronic mail and USENET news it's not enough just to have a SLIP or PPP Internet connection; you also need to have access to a special Internet host or hosts acting as mail or news servers respectively. This access is typically prearranged with some organization, typically the Internet access provider itself. However there are a wealth of other services for which you need only a basic Internet connection. The first example is using anonymous FTP to download information files or shareware. On my Mac the Fetch program (which implements FTP) simply asks me for the name of the host I wish to connect to. Some magic then happens to convert the host name to an IP address (analogous to looking up a phone number) and the connection is made, after which I can download files. The FTP site doesn't ask for an individual password, and doesn't really care who I am. Well, this is almost true. First, all FTP sites ask for some sort of password even if they don't care what it is, and so for anonymous FTP sites Fetch will send your email address (e.g., "hecker@access.digex.net") as the password as a courtesy in case the FTP site is logging access for some reason and wants to record this information. Second, as a mild security measure many FTP sites will check to make sure that the IP address from which you're connecting (e.g., the IP address of my Macintosh) matches the Internet hostname associated with the IP address. In telephone terms this is like getting the phone number of a caller via Caller ID and then looking in a reverse or "criss-cross" directory to find out their name. This is probably a good place for a brief digression on Internet hostnames. As implied earlier, Internet hostnames (like "cap.gwu.edu") are to IP addresses ("128.164.140.32") as people's names are to their phone numbers, and in fact there is a "directory assistance" service to do automatic lookups of IP addresses for a given hostname and vice versa. This automated service is referred to as Domain Name Service or DNS, and is silently invoked by my Macintosh every time I give it an Internet hostname to connect to. The lookup is done by querying a special Internet host called a DNS name server; in my case this server is one maintained by my Internet access provider, and its IP address is yet another of the pieces of configuration information I get when I sign up for SLIP or PPP service. Besides letting me (or more properly, my Macintosh) look up IP addresses automatically, my Internet access provider's DNS name server also maintains entries listing the Internet hostname and IP address of my Mac. This lets remote systems like anonymous FTP sites do the sort of checks I briefly mentioned above. Other than that my Mac's hostname ("ion.digex.net") isn't used for much, as email for me is sent to the mail server's hostname ("access.digex.net") instead. Like directory assistance, DNS name service is essential but fundamentally uninteresting (unless you happen to want to use it and it's not working). It is usually provided by the Internet access provider as a part of basic Internet service and is not really a good candidate for unbundling. (However many Internet access providers do provide an extra cost service whereby you can choose your own personal customized hostname, like "hecker@my-company.com".) Continuing on, Telnet from my Mac works similar to FTP: I tell the NCSA Telnet application the hostname I wish to connect to, it does the silent DNS lookup to find the IP address, and then connects me directly over the Internet to the remote system. The only userid and password required is whatever the remote system might ask for; some Telnet-based services use a dummy or "guest" userid and password, or even no password at all. Connecting to a UNIX system via Telnet normally looks exactly like connecting via a dial-up line. Connecting to more exotic systems like MUDs is very similar (and typically uses Telnet or a Telnet-based protocol underneath): you supply the hostname you wish to connect to, you connect, you signon in some way, you type at the system, you get responses back, you repeat until you're done, and then you logoff and disconnect. The underlying SLIP or PPP Internet connection must be active during the entire session, which may range in time from a few minutes to several hours (or even days, in the case of particularly enthusiastic MUD fans). Gopher and Mosaic/WWW are a little more complicated in the way they work. When I start up either TurboGopher (for Gopher) or NCSA Mosaic (for World Wide Web) they attempt to connect initially to a preset "known host" (or hosts, if alternates have been set up); for Gopher this host is at the University of Minnesota and for Mosaic at the National Center for Supercomputing Applications at the University of Illinois Urbana- Champaign. (Both Gopher and Mosaic can be changed to connect to other initial hosts, or even to not connect to a host at all. However in the case of Mosaic it is not immediately obvious how to reconfigure the software to do this. This is a shame, as the NCSA host is now getting bogged down by all the copies of Mosaic connecting to it every time a new user invokes the program.) Once connected to the initial host, TurboGopher or Mosaic operate in a true "client/server" fashion: the client (i.e., the program running on the Mac) sends a request over the Internet to the server (the program running on the remote host), which in turn sends back a response. All this happens invisibly underneath using a special-purpose communications protocol (Gopher+ for Gopher and HTTP or HyperText Transport Protocol for Mosaic/WWW); all you see on the screen is a graphical "point and click" interface like that characteristic of other Mac- or Windows-based programs. If you pick an item from a Gopher menu or choose to follow a hypertext link in Mosaic then one of three things may happen: you may get a menu ("page" in Mosaic jargon) on the same system, you may get a menu (page) actually stored on another system, or you may invoke a menu item that does something other than just go to another menu. The first case is not that interesting, so we'll skip it. (It's actually a special instance of the second case.) In the second case, for menus (pages) served by another system on the Internet, TurboGopher or Mosaic automatically reconnect to the new system and send the proper low-level commands to retrieve the menu (page) being invoked. As you browse through the menu hierarchy (or the hypertext tree) the Mac programs automatically switch from system to system as needed, so there is no one system to which TurboGopher or Mosaic are "connected". In the third case, when a user invokes a menu item or clicks on a hypertext link, some special action may be performed. One very common action is to initiate automatic downloading of some file. This is implemented essentially by having FTP-like functionality built into TurboGopher and Mosaic, so that by invoking a Gopher or Mosaic item you can fetch any file retrievable via anonymous FTP. If the file is a special type TurboGopher and Mosaic can do also something special with it. For example, if the file were a graphics image in GIF format then after downloading is complete TurboGopher or Mosaic would try to invoke a GIF viewer to show you the file. (Of course, you must already have GIF viewer software on your system, and must have made sure that TurboGopher or Mosaic are configured to use it.) There are lots of other interesting features of Gopher and Mosaic/WWW; however, the most important thing to remember is that, unlike mail and USENET news, you don't have to have anything to use Gopher and Mosaic/WWW except the Internet connection itself. Summary It's been a long and tangled path thus far, and thank you for sticking with it. Here are the key points I want you to take away from this paper: * You can take a Macintosh or a 386 or better Windows-based PC that already has a modem and for a relatively small one-time expenditure (under $50 for TCP/IP and SLIP or PPP software) make it capable of being an full-fledged Internet node. * For an expenditure of between $10 and $40 per month (depending on your location and the amount of competition in the local market) you can sign up with an Internet access provider that will let you connect your PC or Mac to the Internet on an on-demand, dialup basis. What you get for your money is an Internet hostname and IP address (with a directory entry for your system maintained by DNS), a number to call for SLIP or PPP access, and a special SLIP/PPP userid and password to authenticate you and allow your connect time to be tracked. (Note that if your Internet access provider assigns IP addresses "on the fly" then you won't get a hostname or IP address of your own.) Your provider should also supply you with some other miscellaneous configuration information as well, most of which is pure gobbledegook and is needed only when you first configure SLIP or PPP (but is very important at that time). * With just the basic dial-up Internet SLIP/PPP service you can use FTP clients like Fetch to download files, Telnet programs like NCSA Telnet to login to remote systems, Gopher clients like TurboGopher to access Gopher servers, and WWW clients like NCSA Mosaic to access World Wide Web servers. * If your Internet access provider also runs a POP mail server (as almost all do), you can have the mail server receive mail for you and then download it when you're connected, for you to read and respond to offline. Your provider will supply you with an mail userid and password to do this; authentication is done by the mail server. * If your Internet access provider also runs an NNTP news server, you can connect to the news server, select interesting USENET news articles, and download them for reading. You can also post new articles or follow-ups to old articles. The news server will authenticate you (if necessary) based on your IP address and hostname. * In theory electronic mail and USENET news services could be unbundled from basic Internet access ("Internet dial tone"). This is rarely seen today but may become more common as the market for personal Internet access evolves. Note that a higher-speed dedicated Internet connection, via cable for example, would work in a similar manner. The major difference would be in the first two items. First, for a high-speed connection your PC or Mac would not use a modem but rather something like an Ethernet controller board, which typically runs about $100 to $200 on up. (This might hook up to a "cable Ethernet" connection located on your set-top box.) Second, with a dedicated connection there would be no need for an equivalent of the SLIP/PPP userid and password, as the cable company could simply bill you monthly as it does today for cable service. Everything else would work exactly the same way, only faster; the applications software itself (e.g., Eudora, NewsWatcher, TurboGopher, NCSA Mosaic, etc.) would stay the same and would be configured the same. (Whether a TCP/IP connection uses SLIP, PPP, Ethernet, or any other network technology is essentially transparent to the user application.) I should add that typical "Internet over cable" technologies support a high "downstream" bandwidth (i.e., to the home) but a slow "upstream" bandwidth (i.e., to the cable company headend and thence to the Internet). They are thus ideally suited for applications like Mosaic, where you typically download to your PC or Mac a great deal of data in the form of graphics images, sound clips, etc., with only a few bytes of commands going the other direction back to the World Wide Web servers. As a result, "Internet via cable" may be the next frontier for power users currently enjoying the benefits of SLIP and PPP dialup access.