CSE 7348 - class 10

1. CSE 7348 - class 10 • Timeouts on sockets. • Call ALARM which generates the SIGALRM signal when the specified time has expired.. • Block wait for I/O in select (time limit built in). • Use the SO_RCVTIMEO or SO_SNDTIMEO socket options. • All three work with I/O operations (read or write, recvfrom, sendto). • Need a technique to work with connect. • Establish the signal handler for SIGALRM. Sigfunc = Signal (SIGALRM, connect_alarm); if (alarm(nsec != 0) // sets the alarm clock for the process. Then connect(…..)

2. CSE 7348 - class 10 • Point of this function is that if the connection hangs the alarm will fire and the handler will take over. • Note that the handler restores any other handlers. • NB: the timeout value can be reduced but it cannot be extended on a BSD kernel. • Comments on data queuing (page 365). • How does a user determine how much data is queued without reading the data? • Use the recv function with the MSG_PEEK flag. This is one of the flags discussed earlier. This return is the number of bytes in the buffer.

3. CSE 7348 - class 10 • Be wary that the number of bytes available in the buffer can change rapidly. • Some implementations support FIONREAD command of ioctl. This uses a value-result pointer to return the number of bytes in sockets receive queue. • Sockets and standard I/O. • The reads and writes use descriptors and are effectively system calls to the Unix kernel. • It is possible to use the standard I/O library of ANSI C. This is handy in that buffering of the stream is done automatically. • The standard I/O library can be used with sockets with some caveats

4. CSE 7348 - class 10 • A standard I/O stream can be created from any Descriptor by calling the fdopen function. • Or given a standard I/O stream the corresponding descriptor can be determined by calling fileno. (to use select must convert the standard I/O stream to a descriptor). • Standard I/O streams can be made full duplex by opening the stream with an r+. • One caveat; an output func cannot be followed by an input func without a call to fflush, fseek, fsetpos, rewind. • Neither can an input func be followed by an output func without an intervening call to fseek, fsetpos, or rewind. • The problem with these last three is that they all call lseek which fails on a socket.

5. CSE 7348 - class 10 • There are three types of buffering performed by the standard I/O library: • Fully buffered means that the I/O takes place only when the buffer is full. (~ 8192 bytes). • Line buffered (most common) I/O takes place on 0Ah, 0Dh. (LF, CR). • Unbuffered where I/O takes place whenever a call is made. • Most Unix implementations employ the following paradigms. • Stderr is always unbuffered • stdin and stdout are always fully buffered (unless a terminal in which case they are line buffered) • All other streams are fully buffered (unless a terminal which is line buffered).

6. CSE 7348 - class 10 • Unix domain protocols; client server communication on a single host using the TCP API (socket API). • This comes from the need for inter-process communication on a single host; why not use the TCP API? • Other schemes are ‘shared memory’, proprietary comm protocols, polling schemes and a host of other difficult to understand and pointless to reproduce techniques. • This leads of course to the basis of distributed computing; the distribution has to begin with processes on a single platform able to communicate.

7. CSE 7348 - class 10 • Two types of sockets in the Unix Domain; stream sockets (similar to TCP) and datagram sockets (similar to UDP). • Raw sockets are available but are discouraged • Unix domain sockets are an alternative to ICP methods (volume 2 starting next week). • Unix domain sockets are often twice as fast as a TCP socket (intra host comm). (X windows opens a window it checks the server’s host name, window and screen; if the same host then it opens a Unix domain stream to the server). • There is enhanced security on the newer Unix implementations to prevent inter-process hacking on a single host.

8. CSE 7348 - class 10 • Unix domain sockets use a socket address structure. • The protocol family is AF_LOCAL • the pathname is stored struct sockaddr_+un { uint8_t sun_len sa_family_t sun_family; // AF_LOCAL char sun_path[104]; // must be null terminated The path name is of the form /home / surdenau / fake The example on page 375 uses the command line argument to get a pathname to be used in the bind.

9. CSE 7348 - class 10 • The pathname used must have appropriate file access permissions set. (turn off world write bit or system(“o-w”); emply umask per the example. • The default file access should be ugo+rwx then modified by the umask value. • The pathname must be absolute not relative. No links. • The pathname specified in a call to select must be a pathname that is currently bound to an open Unix domain socket of the same type (stream or datagram). • The permission testing is the same as that for a write to a pathname.

10. CSE 7348 - class 10 • Unix domain sockets are similar to TCP sockets in that they provide a stream interface to the process with no record boundaries. • If a call to connect for a Unix domain stream socket finds the listening buffer full, ECONNREFUSED is returned immediately. • Unix domain sockets are effectively unreliable. • Sending a datagram on an unbound Unix domain datagram socket does NOT bind a pathname to the socket. • This means that the user will be unable to send a reply since he has no way of knowing from whence the incoming data

11. CSE 7348 - class 9 • Daemon processes and the inetd superserver. (ch 12). • A daemon (pronounced demon) is a process that runs in the background and is independent of control from all terminals. • Daemons are typically used for various and sundry administrative tasks in the Unix world. • Daemon are typically started by the system admin scripts; (/etc/rc). These daemons have superuser privileges. • The inetd superserver, a Web server and a mail server will typically be started by these initialization scripts. • I.e. daemon is from the Latin daimon which was built on a similar Greek word. A tutelary deity or spirit.

12. CSE 7348 - class 9 • Many network servers are started by the inetd superserver. • Inetd listens for network requests (HTTP, etc) and invokes the actual server. • cron is a daemon; programs it invokes do NOT run as daemons (page 332). • Daemons can be started from user terminals, but will not display error messages there or be interrupted by signals from therein. • Since there must be a way for daemons to output messages the syslog function is used by the syslogd daemon to intercept these messages.

13. CSE 7348 - class 9 • syslogd daemon • Usually started from the initialization scripts, this daemon reads from the / etc / syslog.conf file which specifies what to do with each type of log message to be received. • In addition a Unix domain socket is created and bound to the path / var / run / log. • A UDP socket is created and bound to port 514. • The path / dev / klog is opened and any error messages from the kernel appear as input on this device. • Syslogd runs in an infinite loop using select on the descriptors in the previous steps to be readable.

14. CSE 7348 - class 9 • Now for something interesting: • The individual whom Alan Turing came to visit in 1942, on orders from the British Foreign Office, where Mr. Turing was employed as a code breaker, was John VonNuemann. • Mr. VonNuemann was a legendary gambler, raconteur and world class mathematician at the Princeton Institute for Advanced Studies. Mr. VonNuemann’s wit and humor were so special as to be noted in all remembrances of him. • Mr. VonNuemann, born in Hungary, is widely accounted as the inventor of the ‘data flow’ architecture used by most modern computing machines.

15. CSE 7348 - class 9 • Exactly what Mr. VonNuemann and Mr. Turing spent their six months on is not certain. • It is known that shortly after their visit, Mr. Turing returned to Bechley Park where he devised systems of computation which allowed the breaking of the German ‘Enigma’ code. • After the war, both Mr. Turing and Mr. Von Nuemann designed computational devices. Both of which were far beyond the ability of the electronics industry to realize. • Turing eventually committed suicide, hence the bite (byte) out of the apple.

16. CSE 7348 - class 9 • syslog function • The common technique for logging messages from a terminal is to call the syslog function void syslog ( int priority, const char *message…..) • The priority arg is a combination of a level and a facility. • The message is similar to a format string for printf with the addition of the %m specification and the error message corresponding to the current value of errno. • Levels vary from 0 to 7 with 0 being the highest priority.

17. CSE 7348 - class 9 • The facility of log messages is used to identify the type of process sending the message (LOG_USER is the default). • An example of a facility is a FTP daemon, or the mail system, or the cron daemon. • The purpose of the facility and level is to allow all messages from a given facility or level to be handled the same. • As an example a config file will contain the following; kern.* /dev/console local7.debug /var/log/cisco.log Which specifies that all kernel messages get logged to the console and all debug messages from the local7 facility get appended to the file /var/log/cisco.log.

18. CSE 7348 - class 9 • When an application calls syslog the first time a Unix domain datagram socket is created. Then connect is invoked to the well known pathname of the socket created by the syslogd daemon (var / run / log). • This socket remains open until the application terminates. • As an alternative the openlog and closelog functions can be used. void openlog (const char *ident, int options, int facility); void closelog (void); • ident is a string that is prepended to each log message by syslog. • options argument is the || of one or more constants (figure 12.3). • Normally a Unix domain socket is NOT created on a call to openlog.

19. CSE 7348 - class 9 • The facility argument of openlog specs a default facility for any subsequent calls to syslog that do not spec a facility. • Most daemons call syslog and then only specify a level for any further logging. • daemon_init function: an example of how to daemonize a process. • Call fork and then parent terminates while child continues. Therefore child is in background while inheriting parent process group ID (but maintaining own process ID). • setsid (posix.1 function) creates a new session; the process now becomes the session leader and the group leader of a new process group with no controlling terminal. • Ignore the SIGHUP signal and fork again. Now the second child is running. This guarantees that the second child is no longer the session leader so it cannot acquire a controlling terminal.

20. CSE 7348 - class 9 • daemon_init (continued) • set the global daemon, daemon_proc nonzero ( daemon_proc = 1; ) When this value is nonzero it forces a call to syslog instead of stderr. • Change the working directory to root (generally the working directory particularly for core files). (if a daemon is in a file system that file system cannot be unmounted). • Close all inherited open descriptors. Since there is no limit to the number of descriptors (or the limit is 32k or 64k) the standard approach is to close the first 64 descriptors. • Some daemons open / dev / null for reading and writing and duplicate the descriptor for stdin, stdout, stderr. Therefore any library function can read / write without failure.

21. CSE 7348 - class 9 • daemon_init (continued) • Call openlog. Specify that the process ID should be appended to all log messages. • NB: A daemon should never receive the SIGHUP signal; also the SIGINT and SIGWINCH signals. Therefore these signals can be used to notify the daemon that something has changed (such as the config file). • Page 338, Steven’s sets up the daytime server as a daemon. An excellent exercise and a really great test question.

22. CSE 7348 - class 9 • inetd daemon • In a typical Unix system the servers are all daemonized and started at boot. • All daemons contain nearly the same startup code. • Each daemon takes a slot in the process paper although it is asleep most of the time. • 4.3BSD solved this problem by providing an Internet superserver, the inetd daemon. • This daemon can be used by any server that employs TCP or UDP. It only handles Unix domain sockets. • Simplifies writing daemon processes - most startup details or handled by inetd (no longer need to call daemon_init). • Allows a single process to be waiting for incoming client requests for multiple services, instead of a process for each service.

23. CSE 7348 - class 9 • inetd uses the same techniques to establish itself as daemon_init. • Configuration file is typically in / etc / inetd.conf….. • The config file specifies the services that the superserver is to handle and how to handle a service request. • Sample line; ftp stream tcp nowait root / usr / bin / ftpd ftpd -1 • Name of the server is always passed as the first arg to a program when it is exec’ed. • The names of the fields are service name, socket type, protocol, wait-flag, login-name, server-program, server-program-arguments.

24. CSE 7348 - class 9 [/etc]%cat inetd.conf | more # #ident "@(#)inetd.conf 1.22 95/07/14 SMI" /* SVr4.0 1.5 */ # # # Configuration file for inetd(1M). See inetd.conf(4). # # To re-configure the running inetd process, edit this file, then # send the inetd process a SIGHUP. # # Syntax for socket-based Internet services: # <service_name> <socket_type> <proto> <flags> <user> <server_pathname> <args> # # Syntax for TLI-based Internet services: # # <service_name> tli <proto> <flags> <user> <server_pathname> <args> # • # Ftp and telnet are standard Internet services. • #

25. CSE 7348 - class 9 ftp stream tcp nowait root /usr/sbin/in.ftpd in.ftpd telnet stream tcp nowait root /usr/sbin/in.telnetd in.telnetd # # Tnamed serves the obsolete IEN-116 name server protocol. name dgram udp wait root /usr/sbin/in.tnamed in.tnamed # Shell, login, exec, comsat and talk are BSD protocols. # shell stream tcp nowait root /usr/sbin/in.rshd in.rshd login stream tcp nowait root /usr/sbin/in.rlogind in.rlogind exec stream tcp nowait root /usr/sbin/in.rexecd in.rexecd comsat dgram udp wait root /usr/sbin/in.comsat in.comsat talk dgram udp wait root /usr/sbin/in.talkd in.talkd # # Must run as root (to read /etc/shadow); "-n" turns off logging in utmp/wtmp. # uucp stream tcp nowait root /usr/sbin/in.uucpd in.uucpd # # Tftp service is provided primarily for booting. Most sites run this # only on machines acting as "boot servers."

26. CSE 7348 - class 9 • For each service listed in the inetd.conf file, the inetd daemon will socket, bind, listen (TCP socket). • The maximum number of servers that inetd can handle depends on the max number of descriptors that inetd can create. Each new socket is added to the select descriptor set used by inetd. • For TCP sockets, listen is called (not done for datagram sockets). • After all sockets are created, select is used to wait for a socket to become readable. inetd spends most of its time blocked on this call. • When select returns (socket is readable) accept is called to make the new connection.

27. CSE 7348 - class 9 • The inetd daemon forks and the child process handles the service request. (concurrent server model) • child closes all descriptors other than the socket descriptor that it is handling; the new connected socket for TCP. • The child calls dup three times thereby assigning the socket to descriptors 0, 1, and 2 (stdin, stdout, stderr). • The original socket descriptor is then closed; this means that the child is reading from stdin, writing to stdout or stderr. • The child calls getpwnam to get the password entry for the login-name specified in the config file. • If this field is NOT root, then the child becomes the specified user by executing the setgid and setuid function calls. Inetd is executing with a user ID of 0 the child process inherits the user ID across the fork so it is able to become any user it desires.

28. CSE 7348 - class 9 • The child now does an exec on the appropriate server-program to handle the request, passing all args delineated in the configuration file. • If the socket is a stream socket, the parent must close the connected socket. The parent loops back to select again waiting for another socket to become readable. • The descriptor handling in inetd deserves some attention. • If inetd directs a connection request to port 21, the child will have a descriptor for port 21. • Once the child dups the connected socket to descriptors 0, 1, and 2 the child closes the connected socket. • This means the client is now connected to fd 0, fd 1, fd 2

29. CSE 7348 - class 9 • Once the child calls exec all descriptors remain open across the call so the server uses descriptors 0, 1, and 2 to comm with the client. • On page 344 there is a very fine example of the daemon_inetd function. Review in detail along with Figure 12.12. • In the Daytime server of 12.12, all of the socket creation code has been removed; instead we have daemon_inetd ( argv[0], 0 ); The TCP connection uses descriptor 0. The infinite for loop is gone (invoked once per client connection). Call getpeername with descriptor 0 as a way to determine client protocol address. Use MAXSOCKADDR since we do not know the size of the socket address structure.

30. CSE 7348 - class 9 • What has been done with inetd is actually rather simple; inetd has become the concurrent server for any and all TCP connections. • The same concurrent parent/fork child model is still being used (design pattern??). The model has simply been moved to a higher level of abstraction and all of the various servers have been serviced as exec’s within its child processes. • Most network services are run as daemons (in the background, independent of terminal control). • The output from a daemon is usually handled by the syslogd daemon via the syslog function.

31. CSE 7348 - class 9 • To daemonize a program; • fork to get in background • call setsid to create a new session and become session leader • fork again to avoid obtaining a new controlling terminal • change the working directory appropriately. • Change the file mode creation mask. • Close all unneeded files. • Assignment: Problem 12.1. Turn in by next class in hard format.

32. CSE 7348 - class 9 • Some thoughts on software process. • In 1908 when Igor Stravinsky debuted ‘le Sacre du Printemps’ rioting broke out at the Paris Opera house. • Classical music fans are usually not given to fisticuffs. • The problem is that music and musical beliefs are passionately held. Stravinsky with his dissonance and revolutionary approach to formal music upset a lot of people while wildly pleasing others. He of course changed the course of music in the 20th century. Stravinsky is why we have Jazz and R&R.

33. CSE 7348 - class 9 • Similarly with software processes we have zealots and religiously held beliefs. • Like all deeply held beliefs they are held on the basis of faith; faith and faith alone (not unlike anything believed by anybody). • There is NO demonstrable, repeatable proof or data that any software process, methodology, language or approach is any more beneficial than any other (at least in economic terms). • Which is NOT to say that process, methodology or language are all interchangeable and without value. Quite to the contrary, process and methodology will have an economic impact on the viability of any product; but sales and marketing will have a much larger impact in many instances.

34. CSE 7348 - class 9 • So what is the point? • Temper your beliefs not on the presentations of zealots or other believers in process X or methodology Y. • Instead perform as a scientist and engineer and look for the data which will allow you to accurately quantify the changes wrought by the adaptation of a method, a process or a language. • Remember that the software industry is most like the fashion industry; a large number of customers easily lead by what ever the couture houses of Paris (or Silicon Valley) are currently espousing. • The situation is made frenzied by the billions of dollars at stake.

35. CSE 7348 - class 9 • And in one final bash of the so-called ‘cleanroom’. • Even a Level 1 clean room (less than I particle per cubic yard) is NOT defect free. • No non-trivial system can EVER be fully or accurately specified. • Given the provability of the above, and the outlandish vagaries of the English language, how can a set of requirements, written in English EVER be the basis for an accurate design? • The problem is how do we successfully take a set of flawed requirements, and translate them into a meaningful and accurate notation in the solution space? This translation must incorporate an ability to accommodate CHANGE. Which cleanroom really does not provide.

36. Class 10 • Frequently, services are performed by so-called daemons. A daemon is a program that opens a certain port, and waits for incoming connections. If one occurs, it creates a child process which accepts the connection, while the parent continues to listen for further requests. • This concept has the drawback that for every service offered, a daemon has to run that listens on the port for a connection to occur, which generally means a waste of system resources like swap space. • Thus, almost all installations run a super-server that creates sockets for a number of services, and listens on all of them simultaneously using the select(2) system call. When a remote host requests one of the services, the super-server notices this and spawns the server specified for this port.

37. Class 10 •  The super-server commonly used is inetd, the Internet Daemon. It is started at system boot time, and takes the list of services it is to manage from a startup file named /etc/inetd.conf. In addition to those servers invoked, there are a number of trivial services which are performed by inetd itself called internal services. They include chargen which simply generates a string of characters, and daytime which returns the system's idea of the time of day.

38. Class 10 • Why should you run the HTTP server standalone as opposed to running it from inetd? If your server has a lot of CPU cycles to burn, then there is nothing wrong with running HTTPd from inetd. • Most servers don't. If you run the server from inetd, that means that whenever a request comes in, inetd must first fork a new process, then load the HTTPd binary. Once the HTTPd binary is loaded, HTTPd must then load and parse all of its configuration files (including httpd.conf, access.conf, and mime.types), which is quite a task to be done for each and every request that comes in. • Now, contrast this with running standalone. When HTTPd gets a request, it makes a copy of itself (which requires no loading of a binary since shared text pages are used), and the copy handles the request. The configuration files have already been loaded on startup, and so we don't reload them every time. • In fact, with NCSA HTTPd 1.4 and 1.5, it doesn't even have to make another copy of itself if there is an extra server already running. The parent will just pass off the request to the free child.

39. Class 10 • Common Services • telnet:allows remote users to connect to a host via telnet. Since user passwords are transmitted over the wire in plain text and can therefore be easily sniffed, we recommend disabling the service and using instead a secure terminal access mechanism which encrypts the entire session (such as kerberized telnet or SSH). If telnet access is a must, the service must be wrapped. • ftp:allows remote users to transfer files to/from a host using ftp. Since user passwords are transmitted over the wire in plain text and can therefore be easily sniffed, we recommend disabling the service and using instead a secure file transfer mechanism which encrypts the entire session (SSH). Another solution is to install AFS, thus eliminating the need for an ftp daemon. If ftpd access is a must, the service must be wrapped.

40. Class 10 • Common Services (cont) • shell:allows remote users to run arbitrary commands on a host via the Berkeley rsh utility (via the trusted hosts mechanism using the .rhosts file). Highly insecure. Instead, run the leland kerberalized version of rsh. • login:allows remote users to use the Berkeley rlogin utility to log in to a host without supplying a password (via the trusted hosts mechanism using the .rhosts file). Highly insecure. Instead, use the leland kerberalized version of rlogin. • exec:allow remote users to execute commands on a host without logging in. Exposes remote user passwords on the network, thus Highly insecure. Instead, use the leland kerberalized version of rexec.

41. Class 10 • popper:allows remote users to use POP3 to retrieve their email from the server. Highly insecure. We recommend that you use the leland kerberalized version of popper if you have to run a popper service. Note: If you want to run the kerberalized popper server, you will need another srvtab specifically for that service in order for certain mail readers to work. Please contact srvtab-request@leland for the srvtab.pop srvtab. • comsat:used for incoming mail notification via biff and is largely unecessary. We recommend disabling the service. • finger:allows remote users to use the finger utility to obtain information about arbitrary users on a host. Highly insecure. We recommend disabling the service or using a more secure version such as cfinger. • talk:allows remote users to use talk to have a real time conversation with a user on a host. Considered light security hazard.

42. Class 10 • tftp: allows remote users to transfer files from a host without requiring login. Used primarily by X-terminals and routers. Considered highly insecure. We recommend disabling the service. If tftp access is needed (for bootp clients), we recommend that the "-s" option be used and that the service be wrapped. • uucp: allows remote users to transfer files to/from using the UUCP protocol. I can't honestly remember anyone needing this service who had it enabled. We recommend disabling it and disabling setuid on any uucp binaries. • time: Used for clock synchronization. We recommend disabling the service and using xntp to synchronize your system clock to stanford. • echo, daytime, discard, chargen: These services are used largely for testing and are largely unnecessary. If they are enabled to use UDP, they can be used for a Denial of Service attack. We recommend disabling at least the UDP version of them.

43. Class 10 • bootp, bootps: used for bootp services. We recommend disabling it unless you are running a bootp server. • systat: designed to provide status information about a host. Considered a potential secucrity hazard. We recommend disabling the service. • netstat: designed to provide network status information about a host to remote hosts. Considered a potential secucrity hazard. We recommend disabling the service. • Services based on RPC: RPC based services are used by protocpls such as NFS and NIS. These protocols are a known security hazard. our recommendation is against using NIS or NFS. Kerberos and AFS provide solutions to all the same problems without the security hazard.

44. Class 10 • Configuring inetd at home • Start with an inetd.conf file that is completely commented out. Then add only the services that you need. • Services that you probably want are: (taken from a stock redhat 4.0 machine) telnet stream tcp nowait root /usr/sbin/tcpd in.telnetd ftp stream tcp nowait root /usr/sbin/tcpd in.ftpd -l -a • Things that open your machine up for .rhosts attacks: shellstream tcp nowait root /usr/sbin/tcpd in.rshd login stream tcp nowait root /usr/sbin/tcpd in.rlogind • Things that have no reason running on your machine gopher stream tcp nowait root /usr/sbin/tcpd gn

45. Class 10 • First, inetd is dying because it receives a SIGPIPE when it tries to write to the socket returned by accept since it does not install a signal handler for it. To fix install a signal handler for SIGPIPE. • Now you may be wondering why does a write to the socket returned by accept() generates a SIGPIPE. This bring us to the second issue. It seems that at least under Linux 2.0.X accept() will return a socket in the received queue if it is not in the SYN_SENT or SYN_RECV state, even when it has not gone through the ESTABLISHED state. By doing a stealth scan on the port the socket goes from the SYN_RECV state to the CLOSED state. When you try to read from such a socket you get a SIGPIPE. The sematics of Linux's accept() seems to be non-standard. I wonder what else breaks by not handling SIGPIPE.

46. Class 11 • ICMP Protocol Overview • Internet Control Message Protocol (ICMP), documented in RFC 792, is a required protocol tightly integrated with IP. ICMP messages, delivered in IP packets, are used for out-of-band messages related to network operation or mis-operation. Of course, since ICMP uses IP, ICMP packet delivery is unreliable, so hosts can't count on receiving ICMP packets for any network problem. Some of ICMP's functions are to: • Announce network errors, such as a host or entire portion of the network being unreachable, due to some type of failure. A TCP or UDP packet directed at a port number with no receiver attached is also reported via ICMP. • Announce network congestion. When a router begins buffering too many packets, due to an inability to transmit them as fast as they are being received, it will generate ICMP Source Quench messages. Directed at the sender, these messages should cause the rate of packet transmission to be slowed. Of course, generating too many Source Quench messages would cause even more network congestion, so they are used sparingly.

47. Class 11 • ICMP Overview • Assist Troubleshooting. ICMP supports an Echo function, which just sends a packet on a round--trip between two hosts. Ping, a common network management tool, is based on this feature. Ping will transmit a series of packets, measuring average round--trip times and computing loss percentages. • Announce Timeouts. If an IP packet's TTL field drops to zero, the router discarding the packet will often generate an ICMP packet announcing this fact. TraceRoute is a tool which maps network routes by sending packets with small TTL values and watching the ICMP timeout announcements.

48. Class 11 • IGMP Protocol Overview • Internet Group Management Protocol (IGMP), documented in Appendix I of RFC 1112, allows Internet hosts to participate in multicasting. RFC 1112 describes the basic of multicasting IP traffic, including the format of multicast IP addresses, multicast Ethernet encapsulation, and the concept of a host group. • A host group is the set of hosts interested in traffic for a particular multicast address. Important multicast addresses are documented in the most recent Assigned Numbers RFC, currently RFC 1700. IGMP allows a router to determine which host groups have members on a given network segment. • The exchange of multicast packets between routers is not addressed by IGMP.

49. Class 11 Network Working Group Smoot Carl-Mitchell Request for Comments: 1027 Texas Internet Consulting John S. Quarterman Texas Internet Consulting October 1987 Using ARP to Implement Transparent Subnet Gateways Status of this Memo • This RFC describes the use of the Ethernet Address Resolution Protocol (ARP) by subnet gateways to permit hosts on the connected subnets to communicate without being aware of the existence of subnets, using the technique of "Proxy ARP" [6]. It is based on RFC-950 [1], RFC-922 [2], and RFC-826 [3] and is a restricted subset of the mechanism of RFC-925 [4]. Distribution of this memo is unlimited. Acknowledgment The work described in this memo was performed while the authors were employed by the Computer Sciences Department of the University of Texas at Austin.

50. Class 11 • Introduction The purpose of this memo is to describe in detail the implementation of transparent subnet ARP gateways using the technique of Proxy ARP. The intent is to document this widely used technique. • 1. Motivation • The Ethernet at the University of Texas at Austin is a large installation connecting over ten buildings. It currently has more than one hundred hosts connected to it [5]. The size of the Ethernet and the amount of traffic it handles prohibit tying it together by use of repeaters. The use of subnets provided an attractive alternative for separating the network into smaller distinct units. This is exactly the situation for which Internet subnets as described in RFC-950 are intended. Unfortunately, many vendors had not yet implemented subnets, and it was not practical to modify the more than half a dozen different operating systems running on hosts on the local networks.