- Test - lists.nanog.org

CERT Advisory CA-95:02.binmail.vulnerabilities
by cert-advisory＠cert.org 26 Jan '95

26 Jan '95

============================================================================= CA-95:02 CERT Advisory January 26, 1995 Vulnerabilities in /bin/mail ----------------------------------------------------------------------------- This advisory supersedes CA-91:01a SunOS Mail Vulnerability and CA-91:13 Ultrix Mail Vulnerability. There are vulnerabilities in some versions of /bin/mail. Section III below provides vendor-specific information and an alternative to /bin/mail. As we receive additional information relating to this advisory, we will place it, along with any clarifications, in a CA-95:02.README file. CERT advisories and their associated README files are available by anonymous FTP from info.cert.org. We encourage you to check the README files regularly for updates on advisories that relate to your site. ----------------------------------------------------------------------------- I. Description Some versions of /bin/mail based on BSD 4.3 UNIX are vulnerable because of timing windows in the way /bin/mail uses publicly writable directories. II. Impact Local users (users that have an account on the system) can create or modify root-owned files on the system and can thereby gain unauthorized root access. III. Solutions Either install a patch from your vendor or replace /bin/mail with mail.local. A. Obtain the appropriate patch from your vendor and install it according to the instructions included with the patch. Below is a summary of the vendors listed in the current version of the CA-95:02.README file, and the status they have provided. More complete information, including how to obtain patches, is provided in Appendix A of this advisory and reproduced in the README file associated with this advisory. We will update the README file as we receive more information from vendors. If your vendor's name is not on this list, please contact the vendor directly. Vendor or Source Status ---------------- ------------ Apple Computer, Inc. not vulnerable Berkeley SW Design, Inc. (BSDI) not vulnerable Data General Corp. not vulnerable Digital Equipment Corp. vulnerable, patches available FreeBSD not vulnerable Harris not vulnerable IBM not vulnerable NetBSD not vulnerable NeXT, Inc. not vulnerable Pyramid not vulnerable The Santa Cruz Operation (SCO) see note in Appendix A Solbourne (Grumman) vulnerable - contact vendor Sun Microsystems, Inc. SunOS 4.x vulnerable, patches available, patch revisions coming soon Solaris 2.x not vulnerable B. Replace /bin/mail with mail.local. If you cannot obtain a vendor-supplied replacement for /bin/mail, the CERT Coordination Center recommends using mail.local as a replacement for /bin/mail. Although the current version of mail.local is not a perfect solution, it addresses the vulnerabilities currently being exploited in /bin/mail. As improvements to mail.local become available, we will note them in the README file associated with this advisory. The current version of mail.local has been tested on SunOS 4.1 and Ultrix 4.X systems. Mail.local.c for BSD 4.3 systems, along with a README file containing installation instructions, can be found on the anonymous FTP servers listed below. In addition, Appendix B of this advisory contains the the README file and Appendix C contains mail.local.c. Location Filename -------- -------- info.cert.org /pub/tools/mail.local/mail.local.c MD5 c0d64e740b42f6dc5cc54a2bc37c31b0 coast.cs.purdue.edu /pub/tools/unix/mail.local/mail.local.c MD5 c0d64e740b42f6dc5cc54a2bc37c31b0 --------------------------------------------------------------------------- The CERT Coordination Center thanks Eric Allman, Wolfgang Ley, Karl Strickland, Wietse Venema, and Neil Woods for their contributions to mail.local. --------------------------------------------------------------------------- If you believe that your system has been compromised, contact the CERT Coordination Center or your representative in Forum of Incident Response and Security Teams (FIRST). If you wish to send sensitive incident or vulnerability information to CERT staff by electronic mail, we strongly advise that the e-mail be encrypted. The CERT Coordination Center can support a shared DES key, PGP (public key available via anonymous FTP on info.cert.org) or PEM (contact CERT staff for details). Internet E-mail: cert(a)cert.org Telephone: +1 412-268-7090 (24-hour hotline) CERT personnel answer 8:30 a.m.-5:00 p.m. EST(GMT-5)/EDT(GMT-4), and are on call for emergencies during other hours. Fax: +1 412-268-6989 CERT Coordination Center Software Engineering Institute Carnegie Mellon University Pittsburgh, PA 15213-3890 USA Past advisories, CERT bulletins, information about FIRST representatives, and other information related to computer security are available for anonymous FTP from info.cert.org. CERT is a service mark of Carnegie Mellon University. ............................................................................... Appendix A: Vendor Information Current as of January 26, 1995 See CA-95.02.README for updated information Below is information we have received from vendors who have patches available or upcoming for the vulnerabilities described in this advisory, as well as vendors who have confirmed that their products are not vulnerable. If your vendor's name is not in one of these lists, contact the vendor directly for information on whether their version of sendmail is vulnerable and, if so, the status of patches to address the vulnerabilities. NOT VULNERABLE -------------- The following vendors have reported that their products are NOT vulnerable. Apple Computer, Inc. Berkeley SW Design, Inc. (BSDI) Data General Corp. Harris IBM NeXT, Inc. Pyramid The Santa Cruz Operation (SCO) - not vulnerable, but see note below Sun Microsystems, Inc. - Solaris 2.x (SunOS 4.x is vulnerable; see below) In addition, we have reports that the following products are NOT vulnerable. FreeBSD NetBSD VULNERABLE ---------- We have reports that the following vendors' products ARE vulnerable. Patch information is provided below. ----------------------------- Digital Equipment Corporation Vulnerable: DEC OSF/1 versions 1.2, 1.3, and 2.0 DEC ULTRIX versions 4.3, 4.3A, and 4.4 Obtain and install the appropriate patch according to the instructions included with the patch. The patch that corrects the /bin/mail problem in each case is part of a comprehensive Security Enhanced Kit that addresses other problems as well. This kit has been available since May 17, 1994. It is described in DEC security advisory #0505 and in CERT bulletin VB-94:02. 1. DEC OSF/1 Upgrade/install OSF/1 to a minimum of V2.0 and install Security Enhanced Kit CSCPAT_4061 v1.0. 2. DEC ULTRIX Upgrade/install ULTRIX to a minimum of V4.4 and install Security Enhanced Kit CSCPAT_4060 v1.0. Both kits listed above are available from Digital Equipment Corporation by contacting your normal Digital support channel or by request via DSNlink for electronic transfer. ----------------------------- The Santa Cruz Operation (SCO) SCO's version of /bin/mail is not vulnerable to the problems mentioned in this advisory. SCO's /bin/mail is not setuid-root. However, SCO's /bin/mail has other security-related issues that are fixed by SCO's Support Level Supplement (SLS) uod392a. To get this: ftp: ftp.sco.COM:/SLS/uod392a.Z (compressed disk image) ftp.sco.COM:/SLS/uod392a.ltr.Z (cover letter) ftp.sco.COM:/SLS/README ----------------------------- Solbourne Grumman System Support Corporation now performs all Solbourne software and hardware support. Please contact them for further information. ftp: ftp.nts.gssc.com phone: 1-800-447-2861 e-mail: support(a)nts.gssc.com ----------------------------- Sun Microsystems, Inc. Current patches are listed below, but they are being revised. SunOS Patch MD5 Checksum ------ ----- ------------ 4.1.3 100224-13.tar.Z 90a507017a1a40c4622b3f1f00ce5d2d 4.1.3UI 101436-08.tar.Z 0e64560edc61eb4b3da81a932e8b11e1 The patches can be obtained from local Sun Answer Centers and through anonymous FTP from ftp.uu.net in the /systems/sun/sun-dist directory. In Europe, the patches are available from mcsun.eu.net in the /sun/fixes directory. Appendix B: README File for mail.local.c /bin/mail is a setuid root program with several security vulnerabilities. If you cannot obtain a vendor-supplied replacement for /bin/mail, the CERT Coordination Center suggests using mail.local as a replacement for /bin/mail. In the early days of UNIX, /bin/mail was used to read and to send e-mail. Over the years, many users have switched to e-mail programs with better user interfaces and more features. On BSD 4.3 based UNIX systems using sendmail, /bin/mail is still being used as the local delivery agent. These systems could be at risk. Systems based on UNIX system III or system IV are not vulnerable. mail.local is a replacement for the /bin/mail program. It is only a delivery agent for sendmail and does not have a user interface. It is distributed as a C source file. For operating systems based on BSD 4.3, mail.local.c from a BSD 4.4 distribution will not compile. The version of mail.local.c in this directory was ported to BSD 4.3 by Eric Allman. It should compile and operate on most BSD 4.3 systems. It has been tested on SunOS 4.1.x and Ultrix 4.x systems. To install mail.local, edit the source file to set the _PATH_MAILDIR to the directory where users' spooled mail files are located. The default is "/var/spool/mail". SunOS % cc -Bstatic -O -o mail.local mail.local.c Ultrix % cc -O -o mail.local mail.local.c -Dultrix As root: # mv mail.local $INSTALL_DIR Substitute $INSTALL_DIR for the full pathname of the directory where mail.local will be installed. # chown root $INSTALL_DIR/mail.local # chmod 4711 $INSTALL_DIR/mail.local Edit the sendmail.cf file (in /etc or /usr/lib) search for Mlocal. On that line, replace /bin/mail with $INSTALL_DIR/mail.local. Restart the sendmail process. For versions of sendmail using frozen configuration files, it is important to refreeze the configuration file before restarting the sendmail process. Test the e-mail system. When you are satisfied that everything is working, disable the setuid root bit on the /bin/mail program. # chmod 0711 /bin/mail OR # chmod 0711 /usr/bin/mail **************************************************************************** * The CERT Coordination Center will not formally review, evaluate, or * * endorse the program described. The decision to use the program * * described is the responsibility of each user or organization and we * * encourage each organization to thoroughly evaluate this program * * before installation or use. * **************************************************************************** Appendix C: mail.local.c /*- * Copyright (c) 1990, 1993, 1994 * The Regents of the University of California. All rights reserved. * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: * 1. Redistributions of source code must retain the above copyright * notice, this list of conditions and the following disclaimer. * 2. Redistributions in binary form must reproduce the above copyright * notice, this list of conditions and the following disclaimer in the * documentation and/or other materials provided with the distribution. * 3. All advertising materials mentioning features or use of this software * must display the following acknowledgement: * This product includes software developed by the University of * California, Berkeley and its contributors. * 4. Neither the name of the University nor the names of its contributors * may be used to endorse or promote products derived from this software * without specific prior written permission. * * THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE * ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE. */ #ifndef lint static char copyright[] = "@(#) Copyright (c) 1990, 1993, 1994\n\ The Regents of the University of California. All rights reserved.\n"; #endif /* not lint */ #ifndef lint static char sccsid[] = "@(#)mail.local.c 8.18 (Berkeley) 1/25/95"; #endif /* not lint */ /* * This is not intended to compile on System V derived systems * such as Solaris or HP-UX, since they use a totally different * approach to mailboxes (essentially, they have a setgid program * rather than setuid, and they rely on the ability to "give away" * files to do their work). IT IS NOT A BUG that this doesn't * compile on such architectures. */ #include <sys/param.h> #include <sys/stat.h> #include <sys/socket.h> #include <netinet/in.h> #include <errno.h> #include <fcntl.h> #include <netdb.h> #include <pwd.h> #include <stdio.h> #include <stdlib.h> #include <string.h> #include <sysexits.h> #include <syslog.h> #include <time.h> #include <unistd.h> #include <ctype.h> #if __STDC__ #include <stdarg.h> #else #include <varargs.h> #endif #ifndef LOCK_EX # include <sys/file.h> #endif #ifdef BSD4_4 # include "pathnames.h" #endif #ifndef __P # ifdef __STDC__ # define __P(protos) protos # else # define __P(protos) () # define const # endif #endif #ifndef __dead # if defined(__GNUC__) && (__GNUC__ < 2 || __GNUC_MINOR__ < 5) && !defined(__STRICT_ANSI__) # define __dead __volatile # else # define __dead # endif #endif #ifndef BSD4_4 # define _BSD_VA_LIST_ va_list extern char *strerror __P((int)); #endif #ifndef _PATH_LOCTMP # define _PATH_LOCTMP "/tmp/local.XXXXXX" #endif #ifndef _PATH_MAILDIR # define _PATH_MAILDIR "/var/spool/mail" #endif #ifndef S_ISREG # define S_ISREG(mode) (((mode) & _S_IFMT) == S_IFREG) #endif int eval = EX_OK; /* sysexits.h error value. */ void deliver __P((int, char *)); void e_to_sys __P((int)); __dead void err __P((const char *, ...)); void notifybiff __P((char *)); int store __P((char *)); void usage __P((void)); void vwarn __P((const char *, _BSD_VA_LIST_)); void warn __P((const char *, ...)); int main(argc, argv) int argc; char *argv[]; { struct passwd *pw; int ch, fd; uid_t uid; char *from; extern char *optarg; extern int optind; /* make sure we have some open file descriptors */ for (fd = 10; fd < 30; fd++) (void) close(fd); /* use a reasonable umask */ (void) umask(0077); #ifdef LOG_MAIL openlog("mail.local", 0, LOG_MAIL); #else openlog("mail.local", 0); #endif from = NULL; while ((ch = getopt(argc, argv, "df:r:")) != EOF) switch(ch) { case 'd': /* Backward compatible. */ break; case 'f': case 'r': /* Backward compatible. */ if (from != NULL) { warn("multiple -f options"); usage(); } from = optarg; break; case '?': default: usage(); } argc -= optind; argv += optind; if (!*argv) usage(); /* * If from not specified, use the name from getlogin() if the * uid matches, otherwise, use the name from the password file * corresponding to the uid. */ uid = getuid(); if (!from && (!(from = getlogin()) || !(pw = getpwnam(from)) || pw->pw_uid != uid)) from = (pw = getpwuid(uid)) ? pw->pw_name : "???"; /* * There is no way to distinguish the error status of one delivery * from the rest of the deliveries. So, if we failed hard on one * or more deliveries, but had no failures on any of the others, we * return a hard failure. If we failed temporarily on one or more * deliveries, we return a temporary failure regardless of the other * failures. This results in the delivery being reattempted later * at the expense of repeated failures and multiple deliveries. */ for (fd = store(from); *argv; ++argv) deliver(fd, *argv); exit(eval); } int store(from) char *from; { FILE *fp; time_t tval; int fd, eline; char line[2048]; char tmpbuf[sizeof _PATH_LOCTMP + 1]; strcpy(tmpbuf, _PATH_LOCTMP); if ((fd = mkstemp(tmpbuf)) == -1 || (fp = fdopen(fd, "w+")) == NULL) { e_to_sys(errno); err("unable to open temporary file"); } (void)unlink(tmpbuf); (void)time(&tval); (void)fprintf(fp, "From %s %s", from, ctime(&tval)); line[0] = '\0'; for (eline = 1; fgets(line, sizeof(line), stdin);) { if (line[0] == '\n') eline = 1; else { if (eline && line[0] == 'F' && !memcmp(line, "From ", 5)) (void)putc('>', fp); eline = 0; } (void)fprintf(fp, "%s", line); if (ferror(fp)) { e_to_sys(errno); err("temporary file write error"); } } /* If message not newline terminated, need an extra. */ if (!strchr(line, '\n')) (void)putc('\n', fp); /* Output a newline; note, empty messages are allowed. */ (void)putc('\n', fp); if (fflush(fp) == EOF || ferror(fp)) { e_to_sys(errno); err("temporary file write error"); } return (fd); } void deliver(fd, name) int fd; char *name; { struct stat fsb, sb; struct passwd *pw; int mbfd, nr, nw, off; char *p; char biffmsg[100], buf[8*1024], path[MAXPATHLEN]; off_t curoff; /* * Disallow delivery to unknown names -- special mailboxes can be * handled in the sendmail aliases file. */ if (!(pw = getpwnam(name))) { if (eval != EX_TEMPFAIL) eval = EX_UNAVAILABLE; warn("unknown name: %s", name); return; } /* * Keep name reasonably short to avoid buffer overruns. * This isn't necessary on BSD because of the proper * definition of snprintf(), but it can cause problems * on other systems. * Also, clear out any bogus characters. */ if (strlen(name) > 40) name[40] = '\0'; for (p = name; *p != '\0'; p++) { if (!isascii(*p)) *p &= 0x7f; else if (!isprint(*p)) *p = '.'; } (void)snprintf(path, sizeof(path), "%s/%s", _PATH_MAILDIR, name); /* * If the mailbox is linked or a symlink, fail. There's an obvious * race here, that the file was replaced with a symbolic link after * the lstat returned, but before the open. We attempt to detect * this by comparing the original stat information and information * returned by an fstat of the file descriptor returned by the open. * * NB: this is a symptom of a larger problem, that the mail spooling * directory is writeable by the wrong users. If that directory is * writeable, system security is compromised for other reasons, and * it cannot be fixed here. * * If we created the mailbox, set the owner/group. If that fails, * just return. Another process may have already opened it, so we * can't unlink it. Historically, binmail set the owner/group at * each mail delivery. We no longer do this, assuming that if the * ownership or permissions were changed there was a reason. * * XXX * open(2) should support flock'ing the file. */ tryagain: lockmbox(path); if (lstat(path, &sb)) { mbfd = open(path, O_APPEND|O_CREAT|O_EXCL|O_WRONLY, S_IRUSR|S_IWUSR); if (mbfd == -1) { if (errno == EEXIST) goto tryagain; } else if (fchown(mbfd, pw->pw_uid, pw->pw_gid)) { e_to_sys(errno); warn("chown %u.%u: %s", pw->pw_uid, pw->pw_gid, name); unlockmbox(); return; } } else if (sb.st_nlink != 1 || !S_ISREG(sb.st_mode)) { e_to_sys(errno); warn("%s: irregular file", path); unlockmbox(); return; } else if (sb.st_uid != pw->pw_uid) { warn("%s: wrong ownership (%d)", path, sb.st_uid); unlockmbox(); return; } else { mbfd = open(path, O_APPEND|O_WRONLY, 0); if (mbfd != -1 && (fstat(mbfd, &fsb) || fsb.st_nlink != 1 || !S_ISREG(fsb.st_mode) || sb.st_dev != fsb.st_dev || sb.st_ino != fsb.st_ino || sb.st_uid != fsb.st_uid)) { warn("%s: file changed after open", path); (void)close(mbfd); unlockmbox(); return; } } if (mbfd == -1) { e_to_sys(errno); warn("%s: %s", path, strerror(errno)); unlockmbox(); return; } /* Wait until we can get a lock on the file. */ if (flock(mbfd, LOCK_EX)) { e_to_sys(errno); warn("%s: %s", path, strerror(errno)); unlockmbox(); goto err1; } /* Get the starting offset of the new message for biff. */ curoff = lseek(mbfd, (off_t)0, SEEK_END); (void)snprintf(biffmsg, sizeof(biffmsg), sizeof curoff > sizeof(long) ? "%s@%qd\n" : "%s@%ld\n", name, curoff); /* Copy the message into the file. */ if (lseek(fd, (off_t)0, SEEK_SET) == (off_t)-1) { e_to_sys(errno); warn("temporary file: %s", strerror(errno)); goto err1; } while ((nr = read(fd, buf, sizeof(buf))) > 0) for (off = 0; off < nr; off += nw) if ((nw = write(mbfd, buf + off, nr - off)) < 0) { e_to_sys(errno); warn("%s: %s", path, strerror(errno)); goto err2;; } if (nr < 0) { e_to_sys(errno); warn("temporary file: %s", strerror(errno)); goto err2;; } /* Flush to disk, don't wait for update. */ if (fsync(mbfd)) { e_to_sys(errno); warn("%s: %s", path, strerror(errno)); err2: (void)ftruncate(mbfd, curoff); err1: (void)close(mbfd); unlockmbox(); return; } /* Close and check -- NFS doesn't write until the close. */ if (close(mbfd)) { e_to_sys(errno); warn("%s: %s", path, strerror(errno)); unlockmbox(); return; } unlockmbox(); notifybiff(biffmsg); } /* * user.lock files are necessary for compatibility with other * systems, e.g., when the mail spool file is NFS exported. * Alas, mailbox locking is more than just a local matter. * EPA 11/94. */ char lockname[MAXPATHLEN]; int locked = 0; lockmbox(path) char *path; { int statfailed = 0; if (locked) return; sprintf(lockname, "%s.lock", path); for (;; sleep(5)) { int fd; struct stat st; time_t now; fd = open(lockname, O_WRONLY|O_EXCL|O_CREAT, 0); if (fd >= 0) { locked = 1; close(fd); return; } if (stat(lockname, &st) < 0) { if (statfailed++ > 5) return; continue; } statfailed = 0; time(&now); if (now < st.st_ctime + 300) continue; unlink(lockname); } } unlockmbox() { if (!locked) return; unlink(lockname); locked = 0; } void notifybiff(msg) char *msg; { static struct sockaddr_in addr; static int f = -1; struct hostent *hp; struct servent *sp; int len; if (!addr.sin_family) { /* Be silent if biff service not available. */ if (!(sp = getservbyname("biff", "udp"))) return; if (!(hp = gethostbyname("localhost"))) { warn("localhost: %s", strerror(errno)); return; } addr.sin_family = hp->h_addrtype; memcpy(&addr.sin_addr, hp->h_addr, hp->h_length); addr.sin_port = sp->s_port; } if (f < 0 && (f = socket(AF_INET, SOCK_DGRAM, 0)) == -1) { warn("socket: %s", strerror(errno)); return; } len = strlen(msg) + 1; if (sendto(f, msg, len, 0, (struct sockaddr *)&addr, sizeof(addr)) != len) warn("sendto biff: %s", strerror(errno)); } void usage() { eval = EX_USAGE; err("usage: mail.local [-f from] user ..."); } #if __STDC__ void err(const char *fmt, ...) #else void err(fmt, va_alist) const char *fmt; va_dcl #endif { va_list ap; #if __STDC__ va_start(ap, fmt); #else va_start(ap); #endif vwarn(fmt, ap); va_end(ap); exit(eval); } void #if __STDC__ warn(const char *fmt, ...) #else warn(fmt, va_alist) const char *fmt; va_dcl #endif { va_list ap; #if __STDC__ va_start(ap, fmt); #else va_start(ap); #endif vwarn(fmt, ap); va_end(ap); } void vwarn(fmt, ap) const char *fmt; _BSD_VA_LIST_ ap; { /* * Log the message to stderr. * * Don't use LOG_PERROR as an openlog() flag to do this, * it's not portable enough. */ if (eval != EX_USAGE) (void)fprintf(stderr, "mail.local: "); (void)vfprintf(stderr, fmt, ap); (void)fprintf(stderr, "\n"); #ifndef ultrix /* Log the message to syslog. */ vsyslog(LOG_ERR, fmt, ap); #else { char fmtbuf[10240]; (void) sprintf(fmtbuf, fmt, ap); syslog(LOG_ERR, "%s", fmtbuf); } #endif } /* * e_to_sys -- * Guess which errno's are temporary. Gag me. */ void e_to_sys(num) int num; { /* Temporary failures override hard errors. */ if (eval == EX_TEMPFAIL) return; switch(num) { /* Hopefully temporary errors. */ #ifdef EAGAIN case EAGAIN: /* Resource temporarily unavailable */ #endif #ifdef EDQUOT case EDQUOT: /* Disc quota exceeded */ #endif #ifdef EBUSY case EBUSY: /* Device busy */ #endif #ifdef EPROCLIM case EPROCLIM: /* Too many processes */ #endif #ifdef EUSERS case EUSERS: /* Too many users */ #endif #ifdef ECONNABORTED case ECONNABORTED: /* Software caused connection abort */ #endif #ifdef ECONNREFUSED case ECONNREFUSED: /* Connection refused */ #endif #ifdef ECONNRESET case ECONNRESET: /* Connection reset by peer */ #endif #ifdef EDEADLK case EDEADLK: /* Resource deadlock avoided */ #endif #ifdef EFBIG case EFBIG: /* File too large */ #endif #ifdef EHOSTDOWN case EHOSTDOWN: /* Host is down */ #endif #ifdef EHOSTUNREACH case EHOSTUNREACH: /* No route to host */ #endif #ifdef EMFILE case EMFILE: /* Too many open files */ #endif #ifdef ENETDOWN case ENETDOWN: /* Network is down */ #endif #ifdef ENETRESET case ENETRESET: /* Network dropped connection on reset */ #endif #ifdef ENETUNREACH case ENETUNREACH: /* Network is unreachable */ #endif #ifdef ENFILE case ENFILE: /* Too many open files in system */ #endif #ifdef ENOBUFS case ENOBUFS: /* No buffer space available */ #endif #ifdef ENOMEM case ENOMEM: /* Cannot allocate memory */ #endif #ifdef ENOSPC case ENOSPC: /* No space left on device */ #endif #ifdef EROFS case EROFS: /* Read-only file system */ #endif #ifdef ESTALE case ESTALE: /* Stale NFS file handle */ #endif #ifdef ETIMEDOUT case ETIMEDOUT: /* Connection timed out */ #endif #if defined(EWOULDBLOCK) && EWOULDBLOCK != EAGAIN && EWOULDBLOCK != EDEADLK case EWOULDBLOCK: /* Operation would block. */ #endif eval = EX_TEMPFAIL; break; default: eval = EX_UNAVAILABLE; break; } } #ifndef BSD4_4 char * strerror(eno) int eno; { extern int sys_nerr; extern char *sys_errlist[]; static char ebuf[60]; if (eno >= 0 && eno <= sys_nerr) return sys_errlist[eno]; (void) sprintf(ebuf, "Error %d", eno); return ebuf; } #if __STDC__ snprintf(char *buf, int bufsiz, const char *fmt, ...) #else snprintf(buf, bufsiz, fmt, va_alist) char *buf; int bufsiz; const char *fmt; va_dcl #endif { va_list ap; #if __STDC__ va_start(ap, fmt); #else va_start(ap); #endif vsprintf(buf, fmt, ap); va_end(ap); } #endif #ifdef ultrix /* * Copyright (c) 1987, 1993 * The Regents of the University of California. All rights reserved. * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: * 1. Redistributions of source code must retain the above copyright * notice, this list of conditions and the following disclaimer. * 2. Redistributions in binary form must reproduce the above copyright * notice, this list of conditions and the following disclaimer in the * documentation and/or other materials provided with the distribution. * 3. All advertising materials mentioning features or use of this software * must display the following acknowledgement: * This product includes software developed by the University of * California, Berkeley and its contributors. * 4. Neither the name of the University nor the names of its contributors * may be used to endorse or promote products derived from this software * without specific prior written permission. * * THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE * ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE. */ #if defined(LIBC_SCCS) && !defined(lint) static char sccsid[] = "@(#)mktemp.c 8.1 (Berkeley) 6/4/93"; #endif /* LIBC_SCCS and not lint */ #include <sys/types.h> #include <sys/stat.h> #include <fcntl.h> #include <errno.h> #include <stdio.h> #include <ctype.h> static int _gettemp(); mkstemp(path) char *path; { int fd; return (_gettemp(path, &fd) ? fd : -1); } /* char * mktemp(path) char *path; { return(_gettemp(path, (int *)NULL) ? path : (char *)NULL); } */ static _gettemp(path, doopen) char *path; register int *doopen; { extern int errno; register char *start, *trv; struct stat sbuf; u_int pid; pid = getpid(); for (trv = path; *trv; ++trv); /* extra X's get set to 0's */ while (*--trv == 'X') { *trv = (pid % 10) + '0'; pid /= 10; } /* * check the target directory; if you have six X's and it * doesn't exist this runs for a *very* long time. */ for (start = trv + 1;; --trv) { if (trv <= path) break; if (*trv == '/') { *trv = '\0'; if (stat(path, &sbuf)) return(0); if (!S_ISDIR(sbuf.st_mode)) { errno = ENOTDIR; return(0); } *trv = '/'; break; } } for (;;) { if (doopen) { if ((*doopen = open(path, O_CREAT|O_EXCL|O_RDWR, 0600)) >= 0) return(1); if (errno != EEXIST) return(0); } else if (stat(path, &sbuf)) return(errno == ENOENT ? 1 : 0); /* tricky little algorithm for backward compatibility */ for (trv = start;;) { if (!*trv) return(0); if (*trv == 'z') *trv++ = 'a'; else { if (isdigit(*trv)) *trv = 'a'; else ++*trv; break; } } } /*NOTREACHED*/ } #endif

1 0

Re: Agenda suggestions?
by Elise Gerich 26 Jan '95

26 Jan '95

Sean, Thanks for bringing this up (agneda topics). }-- Security problems operators can fix } [or, how to let your customers be used to break into } interesting places] } (route announcement filtering vs. routing attacks } outbound packet filters on CPE routers vs. spoofing } attacks like the ones CERT announced recently) }This could go fairly quickly. Is there anyone who will volunteer to lead this discussion? } -- Routing flaps considered harmful Is there a volunteer to lead this topic? | 2) technical presentation on what is a route server Yakov Rekhter has volunteered to give a technical presentation on the RA's Route Server implementation. } Is this going to be from an RA/RS perspective? If } so, some talk about converting extremely complicated } policy now embedded in border Ciscos to something } that can be put into the RA/RSes would be neato. } (Also what that policy ought to be in very broad } terms ("NAP/MAE technical etiquette") might be } useful as a short side-line talk.) I have a candidate in mind for addressing this - let me check. } [or, Peter Lothberg politely questions the current } implementation's utility] Peter has not volunteered to make a presentation. There is room on the agenda for a presentation on the utility of the route server concept or implementation (RA since noone has volunteered infor on another implmentation). } 5) end-to-end problem resolution - is it possible? I have approached two candidates to lead this discussion - neither have confirmed yet. Other agenda topics are welcome...we should be distributing an agenda sometime this weekend. --Elise

3 2

Re: Agenda suggestions?
by Tired of the Information Superhype 26 Jan '95

26 Jan '95

Vadim Antonov wrote: >Another thing we really need from router manufacturers is >_persistent_ static routes by default. The current behaviour >of one rather popular brand of routers (name witheld to protect >the guilty) is to remove routes if the associated circuit goes >down. We need to change it to have packets to go to the bit >bucket instead, and make the old behaviour be configurable >with an explicit knob. Hm, I would think most would want that behaviour configured in the current way... because it makes network debugging so much easier. Based on many years of beating my head against various network reliability problems, I would say that it's better to have the route go away and let the user know about it than to throw data into the bit bucket. Maybe we could compromise on an option to leave the route there when the circuit goes down, for those network managers who want to receive calls from users saying "My data went into the bit bucket" and then spend some time to figure out that it's because the circuit went down. -- Walt -------

2 1

Re: Agenda suggestions?
by Vadim Antonov 26 Jan '95

26 Jan '95

>I would say that it's better to have the route go away and let the user >know about it than to throw data into the bit bucket. Static routes shouldn't go away. It was a cheap shot to help people who can't configure dynamic routing properly. >Maybe we could compromise on an option to leave the route there when the >circuit goes down, It has to be default to take any effect on global routing flap. Non-default options aren't used by those without a clue; and it is precisely netadmins whith no clue whose networks do most harm to the Internet. >for those network managers who want to receive calls >from users saying "My data went into the bit bucket" and then spend some >time to figure out that it's because the circuit went down. Those "managers" got to fix their routing, ok? --vadim

1 0

Re: Agenda suggestions?
by Vadim Antonov 25 Jan '95

25 Jan '95

smd> This dovetails into the new religion that doing BGP or other smd> dynamic routing with singly-homed customers is a bad idea, smd> even for policy or political reasons. Hm. If it a new religion, will you nominate me for the Prophet? :-) Another thing we really need from router manufacturers is _persistent_ static routes by default. The current behaviour of one rather popular brand of routers (name witheld to protect the guilty) is to remove routes if the associated circuit goes down. We need to change it to have packets to go to the bit bucket instead, and make the old behaviour be configurable with an explicit knob. --vadim

1 0

Re: Agenda suggestions?
by Sean Doran 25 Jan '95

25 Jan '95

| >Routing flaps considered harmful... | A while ago Curtis proposed a scheme for holddowns that | has a property that a holddown time associated with | a route increases with the frequency of this route | flapping -- so that frequently flapping routes getting | progressively long timeouts. This is a good idea, if a bit of a gross and ugly hack at one aspect of the problem (frequent flaps of one specific set of prefixes). There are also ways of helping out right now that aren't dependent on implementation changes to router software and are better general fixes for the sheer number of flaps, imho. Part of what needs doing is a decision about what should give a host unreachable/network unreachable message. Right now it tends to be a box very close to the originator; I would tend to argue that this is no longer necessarily a good idea, and that in the case of statically-routed single-homed internets a box as close as possible to the destination could do that job just as well (with side effects like fewer globally-visible route-flaps). This dovetails into the new religion that doing BGP or other dynamic routing with singly-homed customers is a bad idea, even for policy or political reasons. If it's *really* necessary to do this (people argue that, among other reasons, this is something that should be done so that the CIX router can distinguish CIX member routes from non-CIX-member routes belonging to non-CIX-member resellers), it probably would be better to route them statically and advertise a lie saying that the routes originated in e.g. BGP or EGP with AS XXXX. Sean.

2 1

Agenda suggestions?
by yakov＠watson.ibm.com 25 Jan '95

25 Jan '95

Ref: Your note of Wed, 25 Jan 1995 05:57:53 -0500 >Routing flaps considered harmful... A while ago Curtis proposed a scheme for holddowns that has a property that a holddown time associated with a route increases with the frequency of this route flapping -- so that frequently flapping routes getting progressively long timeouts. Yakov.

2 1

Agenda suggestions?
by epg＠merit.edu 25 Jan '95

25 Jan '95

We are in the process of putting together the agenda for the Feb 9-10 meeting of NANOG. Does anyone have any topics which they would like to see on the agenda? Some suggestions that we have had are: 1) status of the transition to the new NSF Architecture 2) technical presentation on what is a route server 3) discussion on cooperatively rationalizing MBONE routing 4) IPv6 transition 5) end-to-end problem resolution - is it possible? 6) RADB - how to use it 7) ATM testbed results Please send those cards and letters soon - otherwise we'll just have to make up something. --Elise

4 3

Additions to the NSFNET policy-based routing database
by smm＠twain.merit.edu 23 Jan '95

23 Jan '95

------------------------------------------------------------------------------ The PRDB and this "NWG report" will be retired very soon. Details below. ------------------------------------------------------------------------------ The following changes have been made to the NSFNET policy-based routing database and will be installed on the backbone by 08:00 EST : Total = As + Bs + Cs + Aggs Registered Networks 45617 = 30 5241 37855 2491 Configured Networks 42580 = 30 5184 34939 2427 Added Networks 144 = 0 4 128 12 Deleted Networks 2 = 0 1 0 1 IP address Net name Country Priority:AS ---------- -------- ------- ----------- 146.243/16 MASS-GOV-NET C:US 1:3561(218) 2:3561(11) 3:560 4:701(136) 5:701(134) 152.104/16 HONGKONG-NET C:HK 1:1321 156.8/16 ISCOR-VDB C:ZA 1:1800 2:1240 3:1239 157.200/16 FINNAIR-NET C:FI 1:701(136) 2:701(134) 3:1800 192.17.5/24 INTERTV-DOM C:US 1:3830 2:1800 4:1240 192.22.10/23 APPLICON C:US 1:1225(130) 2:1225(129) 192.22.12/22 APPLICON C:US 1:3561(218) 2:3561(11) 3:1225(131) 4:1225(130) 5:1225(129) 192.22.16/23 APPLICON C:US 1:3561(218) 2:3561(11) 3:1225(131) 4:1225(130) 5:1225(129) 192.22.30/23 APPLICON C:US 1:3561(218) 2:3561(11) 3:1225(131) 4:1225(130) 5:1225(129) 192.22.32/23 APPLICON C:US 1:3561(218) 2:3561(11) 3:1225(131) 4:1225(130) 5:1225(129) 192.22.40/24 APPLICON C:US 1:3561(218) 2:3561(11) 3:1225(131) 4:1225(130) 5:1225(129) 192.22.50/24 APPLICON C:US 1:3561(218) 2:3561(11) 3:1225(131) 4:1225(130) 5:1225(129) 192.58.172/24 LOCKHEED-ESC C:US 1:1332 2:1321 192.68.118/24 PGE-CNET-C-68-118 C:US 1:2149 2:174 192.68.119/24 PGE-CNET-C-68-119 C:US 1:2149 2:174 192.68.120/24 PGE-CNET-C-68-120 C:US 1:2149 2:174 192.68.121/24 PGE-CNET-C-68-121 C:US 1:2149 2:174 192.68.122/24 PGE-CNET-C-68-122 C:US 1:2149 2:174 192.68.123/24 PGE-CNET-C-68-123 C:US 1:2149 2:174 192.68.124/24 PGE-CNET-C-68-124 C:US 1:2149 2:174 192.68.125/24 PGE-CNET-C-68-125 C:US 1:2149 2:174 192.80.215/24 PGE-CNET1 C:US 1:2149 2:174 192.80.216/24 PGE-CNET2 C:US 1:2149 2:174 192.80.217/24 PGE-CNET3 C:US 1:2149 2:174 192.80.218/24 PGE-CNET4 C:US 1:2149 2:174 192.80.219/24 PGE-CNET5 C:US 1:2149 2:174 192.80.220/24 PGE-CNET6 C:US 1:2149 2:174 192.80.221/24 PGE-CNET7 C:US 1:2149 2:174 192.80.222/24 PGE-CNET8 C:US 1:2149 2:174 192.80.223/24 PGE-CNET9 C:US 1:2149 2:174 192.80.224/24 PGE-CNET10 C:US 1:2149 2:174 192.80.225/24 PGE-CNET11 C:US 1:2149 2:174 192.80.226/24 PGE-CNET12 C:US 1:2149 2:174 192.80.227/24 PGE-CNET13 C:US 1:2149 2:174 192.80.228/24 PGE-CNET14 C:US 1:2149 2:174 192.80.229/24 PGE-CNET15 C:US 1:2149 2:174 192.80.230/24 PGE-CNET16 C:US 1:2149 2:174 192.80.231/24 PGE-CNET17 C:US 1:2149 2:174 192.80.232/24 PGE-CNET18 C:US 1:2149 2:174 192.80.233/24 PGE-CNET19 C:US 1:2149 2:174 192.80.234/24 PGE-CNET20 C:US 1:2149 2:174 192.80.235/24 PGE-CNET21 C:US 1:2149 2:174 192.80.236/24 PGE-CNET22 C:US 1:2149 2:174 192.80.237/24 PGE-CNET23 C:US 1:2149 2:174 192.80.238/24 PGE-CNET24 C:US 1:2149 2:174 192.80.239/24 PGE-CNET25 C:US 1:2149 2:174 192.80.240/24 PGE-CNET26 C:US 1:2149 2:174 192.80.241/24 PGE-CNET27 C:US 1:2149 2:174 192.80.242/24 PGE-CNET28 C:US 1:2149 2:174 192.80.243/24 PGE-CNET29 C:US 1:2149 2:174 192.80.244/24 PGE-CNET30 C:US 1:2149 2:174 192.80.245/24 PGE-CNET31 C:US 1:2149 2:174 192.80.246/24 PGE-CNET32 C:US 1:2149 2:174 192.80.247/24 PGE-CNET33 C:US 1:2149 2:174 192.80.248/24 PGE-CNET34 C:US 1:2149 2:174 192.80.249/24 PGE-CNET35 C:US 1:2149 2:174 192.80.250/24 PGE-CNET36 C:US 1:2149 2:174 192.80.251/24 PGE-CNET37 C:US 1:2149 2:174 192.80.252/24 PGE-CNET38 C:US 1:2149 2:174 192.80.253/24 PGE-CNET39 C:US 1:2149 2:174 192.80.254/24 PGE-CNET40 C:US 1:2149 2:174 192.102.226/24 EDI C:US 1:3561(218) 2:3561(11) 3:1225(131) 4:1225(130) 5:1225(129) 192.111.160/19 PAC-BELL-C1 C:US 1:200(128) 2:200(144) 193.184.75/24 SKIRJA-NET2 C:FI 1:701(136) 2:701(134) 3:1800 194.128/16 UK-PIPEX-194-128 C:GB 1:1849 2:701(136) 3:701(134) 4:1800 198.59.109/24 NETBLK-WESTNET C:US 1:1334 198.59.113/24 NETBLK-WESTNET C:US 1:1334 198.59.115/24 DBACYBER C:US 1:1334 198.59.117/24 CINM2 C:US 1:1334 198.59.165/24 NETBLK-WESTNET C:US 1:1334 198.59.177/24 NETBLK-WESTNET C:US 1:1334 198.59.180/24 NETBLK-WESTNET C:US 1:1334 198.63.163/24 NETBLK-SESQUI-CIDR C:US 1:1334 198.81.215/24 WINCOM-DMZ2 C:CA 1:1325 198.139.125/24 NETBLK-CEDAR-CREST-CO C:US 1:97 198.139.126/24 NETBLK-CEDAR-CREST-CO C:US 1:97 198.139.127/24 NETBLK-CEDAR-CREST-CO C:US 1:97 198.139.128/24 NETBLK-CEDAR-CREST-CO C:US 1:97 198.160.139/24 ATSNET C:US 1:3561(218) 2:3561(11) 3:279 4:86 198.175.187/24 BBC-C C:US 1:1800 2:1239 3:1240 198.203.216/24 FDOTMCCO C:US 1:2551(136) 2:1321 199.26.152/24 CAS-C-NET C:US 1:3561(218) 2:3561(11) 3:1225(131) 4:1225(130) 5:1225(129) 199.164.184/24 SKEPSIS C:US 1:1800 2:1239 3:1240 199.208.130/24 SHARPELAN C:US 1:568(144) 199.208.131/24 SDLAN C:US 1:568(144) 199.208.132/24 PSLAN C:US 1:568(144) 199.208.133/24 TDLAN C:US 1:568(144) 199.208.134/24 OCLAN C:US 1:568(144) 199.208.135/24 CCLAN C:US 1:568(144) 199.208.136/24 BARLAN C:US 1:568(144) 199.208.137/24 SATLAN C:US 1:568(144) 199.208.138/24 REDLAN C:US 1:568(144) 199.208.139/24 ISLAN2 C:US 1:568(144) 199.208.140/24 NCTSNPT C:US 1:568(145) 199.211.253/24 NUWCNET1 C:US 1:568(145) 202.68.0/19 APNIC-CIDR-BLK C:HK 1:1321 204.4.113/24 PSINET-C4 C:US 1:2149 2:174 204.6.57/24 PSINET-C4 C:US 1:2149 2:174 204.6.58/24 PSINET-C4 C:US 1:2149 2:174 204.6.59/24 PSINET-C4 C:US 1:2149 2:174 204.6.83/24 PSINET-C4 C:US 1:2149 2:174 204.69.162/24 OMNINOC-NET C:US 1:3561(218) 2:3561(11) 3:114 204.73.217/24 OJIBWE C:US 1:1225(130) 2:1225(129) 3:1225(131) 4:1239 5:1240 6:1800 204.74.68/24 NET-WCLASS C:US 1:1957 204.75.175/24 SECMEG C:US 1:2149 2:174 204.87.64/24 OKLAOSF-1 C:US 1:93 204.89.187/24 NOSPARROW C:US 1:3561(11) 2:3561(218) 3:1240 4:1239 5:1800 204.120.204/24 NET-APCI C:US 1:1239 2:1800 3:1240 204.128.180/24 GIGOTECH C:US 1:1800 2:1239 3:1240 204.134.0/24 INNSOL C:US 1:1334 204.134.1/24 NETBLK-CSN-BLOCK-6 C:US 1:1334 204.134.2/24 DWF-DOM C:US 1:1334 204.134.3/24 DECCS C:US 1:1334 204.134.4/24 WACKO-NET C:US 1:1334 204.142.79/24 NETBLK-DES2 C:US 1:97 204.142.80/24 NETBLK-DES3 C:US 1:97 204.142.83/24 NETBLK-FCDS-C-142-83 C:US 1:97 204.142.84/24 NETBLK-FCDS-C-142-84 C:US 1:97 204.142.87/24 NETBLK-DALCOMP1 C:US 1:97 204.142.88/24 NETBLK-DALCOMP2 C:US 1:97 204.142.89/24 OPTUS-C-142-89 C:US 1:97 204.142.90/24 OPTUS-C-142-90 C:US 1:97 204.142.91/24 NSLABS2 C:US 1:97 204.142.92/24 NSLABS3 C:US 1:97 204.142.93/24 NETBLK-RIDER4 C:US 1:97 204.142.94/24 NETBLK-RIDER5 C:US 1:97 204.142.95/24 NETBLK-RIDER6 C:US 1:97 204.142.96/24 NETBLK-RIDER7 C:US 1:97 204.142.97/24 NETBLK-RIDER8 C:US 1:97 204.142.98/24 NETBLK-RIDER9 C:US 1:97 204.142.99/24 NETBLK-RIDER10 C:US 1:97 204.142.100/24 NETBLK-RIDER11 C:US 1:97 204.142.111/24 CFRNJ2 C:US 1:97 204.142.112/24 CFRNJ3 C:US 1:97 204.145.166/24 NET-DASHOPS C:US 1:1239 2:1800 3:1240 204.147.224/20 SCRUZ-NET-C2 C:US 1:3561(11) 2:3561(218) 3:1240 4:1239 5:1800 204.153.160/22 CORPCOMM C:US 1:3561(11) 2:3561(218) 3:685 4:73 5:101 204.164.64/24 SML-64 C:US 1:560 2:701(136) 3:701(134) 204.168.92/22 NET-HOUGHTON C:US 1:1239 2:1800 3:1240 204.213.70/23 NET-NEXUS C:US 1:1239 2:1800 3:1240 204.222.24/24 NETBLK-WEBSTER-FLD-C- C:US 1:568(145) 204.222.25/24 NETBLK-WEBSTER-FLD-C- C:US 1:568(145) 204.222.26/24 NETBLK-WEBSTER-FLD-C- C:US 1:568(145) 204.222.27/24 NETBLK-WEBSTER-FLD-C- C:US 1:568(145) Deletions: --131.127/16 ASGARRETT C:US 1:1239 2:1800 3:1240 4:1225(130) 5:1225(129) 6:1225(131) --204.168.112/22 NET-GREATNECK.LIB.NY C:US 1:1239 2:1800 3:1240 Expanded listing, sorted by country, then by organization: ========================================================== The "Expanded Listings" section of this NWG report has been retired since it is sorted by countries and network organization addresses. The replacement configuration generation system is based on the Internet Routing Registry (briefly called the "Global Routing Registry"). See the file ftp.ra.net:pub/radb/OVERVIEW for more information. The remainder of this report will also be retired shortly. AS690 CIDR Squeezings Report: 9795 Nets, 169 ASs, 2643 Aggregates ------------------------------------------------------------------ 9795 (85%) of the ever-announced more-specific routes within aggregates have been withdrawn. 241 of those were withdrawn within the last week. 318 the week before that. 180 the week before that. 169 ASs have registered aggregates in the PRDB. 147 of those are announcing aggregates. 80 have withdrawn at least one more specific route. 2643 Aggregates are configured. 1906 of these were Top-Level Aggregates (not nested in another aggregate). 1454 of these are being announced to AS690. 1026 of those have at least one subnet configured (the other 428 may be saving the Internet future subnet announcements). 855 have stopped announcing at least one configured more specific route. 832 have stopped announcing half of their configured more specific routes. 777 have stopped announcing most (80%) of their more specific routes. See merit.edu:pub/nsfnet/cidr/cidr_savings for more detail. ----------------------------------------------------------- ========================================================== The configuration reports which reflect today's update will be available for anonymous ftp on nic.merit.edu by 08:00 EST : configuration reports -- nic.merit.edu:nsfnet/announced.networks: as-as.now as-gw.now ans_core.now country.now net-comp.now nets.doc nets.non-classful nets.tag.now nets.unl.now NSS routing software configuration files -- nic.merit.edu:nsfnet/backbone.configuration: gated.nss<NSS number>.t3p Information is also avaiable through the PRDB whois server. Type "whois -h prdb.merit.edu help" for details. -------------------------------------------------------------------------- PRDB CHANGES: (Updated January 19, 1994) As of 1/19/95, ACKs and NAKs will no loger be required (or even read) in the processing of NACRs. In early 1995, as part of the transition to the new Internet Routing Registry (IRR), the Policy Routing Database (PRDB) will be retired. Many of the functions of the PRDB (including generation of router configurations for NSFNET) will be produced based on data from the Global Routing Registry. This change to the NSFNET Backbone service will involve the following changes: - The method for submitting new nets to be routed over AS690 will change. Instead of submitting a NACR to nsfnet-admin(a)merit.edu, you will need to submit a "route template" to auto-dbm(a)ra.net . - Additions and entries to the new registry will be made by the Home AS which creates the route for each net, rather than being submitted by a AS690 peer AS. - Most of the PRDB reports (listed above) will no longer be produced. Equivalent information for most of these reports is available from the global Routing Registry. These are major changes to the system. These changes are being made in order to migrate NSFNET customers and the global user community to a global Internet Routing Registry system, which will be more capable of supporting user needs after the termination of the NSFNET Backbone services in April 1995. For more information, set your web browser to http://www.ra.net/rrinfo.html , or use anonymous ftp to obtain the files "OVERVIEW" and from the directory "ftp.ra.net:pub/radb". Merit would like to minimize the number of problems that this transition may cause you. In order to help us help you through the transition, please send your concerns, your needs, and suggestions on how we can make this happen smoothly to merit-ie(a)merit.edu. The archived discussion list "db-disc(a)merit.edu" also exists for discussion of PRDB and RADB issues. Send a message to "db-disc-request(a)merit.edu" to subscribe. --Dale Johnson (dsj(a)merit.edu) -------------------------------------------------------------------------- Please send all requests for configuration changes to nsfnet-admin(a)merit.edu using the NSFNET configuration forms. The forms are available on-line from the nic.merit.edu machine. Use ftp and the anonymous login to get on the machine. Do a "cd nsfnet/announced.networks" and get the files template.net, template.net.README, template.gate, and template.as. *** Note: As of March 1, 1994, NSFNET AUP NACRs must use the template.net *** (NACR) version 7.1, or the NACR will be returned unprocessed. ******************************* --Steven J. Richardson Merit/NSFNET sjr(a)merit.edu

1 0

** Transition updates
by Steven J. Richardson 23 Jan '95

23 Jan '95

Please submit your transition updates ASAP, e.g., not the day before. Thank you, Steve Richardson/Merit

1 0