- Test - lists.nanog.org

Re: CIDR
by Vince Fuller 10 Mar '94

10 Mar '94

With tonights db run, we will be removing more specific routes. Not all of them, just a few @ first. A suggestion: *don't* remove them from the NSFNET database right away, just stop announcing them. That way if you run in to trouble, you can always start announcing them again without having to wait two-to-three days for a database update. --Vince

2 1

CIDR
by yakov＠watson.ibm.com 10 Mar '94

10 Mar '94

Ref: Your note of Thu, 10 Mar 1994 10:50:24 -0500 Jessica, >I believe it is still the case at the moment (test & trial stage) Are there any plans to move beyond the "test & trial stage" ? If yes, then do we have any concrete dates for when the individual networks (that form a single prefix) will be removed from the routing ? Yakov.

1 0

CIDR
by yakov＠watson.ibm.com 10 Mar '94

10 Mar '94

Jessica, >Below are some aggregate routes.... Do we still propagate through the Internet the individual network numbers associated with these routes ? Yakov

3 2

A few thoughts on [Re: Invitation to Network Providers]
by Robert E. Seastrom 10 Mar '94

10 Mar '94

> The software program will also obtain, or alternatively ask > for, the name of the network provider and/or the brand of the > communications server used at the network provider's POP (typically > CISCO, Livingston, Emulex, or other hardware). This will enable > CSI's program to construct the brief but critical connect-time > SLIP/PPP negotiation macro used for initializing the network > connection and in some cases, for obtaining the user's dynamic IP > address assigned at connect time by some network providers. Handwaving this is inviting trouble. A macro language for writing chat scripts (such as Apple's ARA CCL, which sucks but works) needs to be specified, and the scripts should be delivered in human-readable/editable (eg. text file, not compiled) format so that they can be tweaked to fit any local weirdnesses for a particular provider or have hacks installed by a savvy user to get around local problems like a cranky PBX (ie, don't let the desire to be user-friendly eclipse the need to be easily reconfigurable by a knowledgable person). Moreover, hooks for more parameters than just UserID, Password, IPAddress, PhoneNumber, and MaxSpeed need to be provided to support things like secondary passwords, callback, etc. DefaultGatewayIP is superfluous in the case of the single leaf node connected to a terminal server running PPP. Since nothing else here addresses the complexities of routing to a subnet, I conclude that this proposal only addresses the former case. You may as well just dike that field out. For POP3, NNTP, and SMTP, you need to specify return addresses and full- names. These will not necessarily be the same as the username in the terminal emulator or PPP session, for obvious reasons. I like the idea of a configuration language that hides the nuts and bolts of PPP from Joe and Jane Luddite with their 486-PC-running-Windows <grin> but I think it needs lots more thought before it is viable in the wide variety of circumstances it will find itself in out there in real world. Oh yeah, I don't think it's such a hot idea to promulgate a new standard in which (a) passwords are stored online in cleartext, and (b) reusable passwords are passed back and forth over the net in cleartext. Better by far to specify Kerberos or a session key handshake for user authentication, and maybe even encrypt the entire session... Just my two cents worth... ---Rob

1 0

Re: CIDR in the Internet
by Jordan Becker 10 Mar '94

10 Mar '94

> Yakov: > > Below are some aggregate routes known to NSF/ANSnet backbone > currently. There are more aggregate routes have been configured to be > advertise to the BB. > > CIDR routes in Ann Arbor ENSS's routing table: > > 193.157.64 140.222.41.2 UG (0)0 ffff e000 > 199.1.254 140.222.41.2 UG (0)0 ffff fe00 > 198.66 140.222.41.2 UG (0)0 ffff 8000 > > There are also other live CIDR routes exists in other NSP's routing > table. The prefixes are announced to the bgpd mailing list by the > NSPs. > > --jessica For those interested, the peers that AS690 now has established BGP4 sessions with include: AlterNet (AS701) BARRNet (AS200) CERFNet (AS1740, AS1838) COREN (AS2882) Dante (AS1133, AS1674) ESNet (AS293) ICMNet (AS1240, AS1800) NASA (AS297, AS372) NEARNet (AS560) OARNet (AS600) SESQUINet (AS114) SURANet (AS86)

1 0

CIDR in the Internet
by yakov＠watson.ibm.com 09 Mar '94

09 Mar '94

Ref: Your note of Wed, 9 Mar 1994 16:06:08 -0500 Dale, >Here are the aggregates listed... Does that mean that all the individual network numbers that compose the listed aggregates are no longer announced in the Internet ? Yakov

2 1

Re: CIDR in the Internet
by Dale S. Johnson 09 Mar '94

09 Mar '94

Yakov, FYI: Here are the aggregates listed in the PRDB as of today: * 192.204.248/22 PREPNET-C N 1:574 * 193.157.64/19 RITONET N 1:1800 2:1879 3:1133 4:1240 * 198.6.252/22 UUNET-BGP-TEST N 1:701 2:702 * 198.63.0/16 SESQUI-CIDR N 1:114 * 198.64.0/15 SESQUI-CIDR N 1:114 * 198.66.0/16 SESQUI-CIDR N 1:114 * 198.66.0/17 NETBLK-SESQUI-CIDR N 1:114 * 198.213.0/16 THENET-CIDR-C1 N 1:114 * 198.214.0/15 THENET-CIDR-C2 N 1:114 * 198.216.0/16 THENET-CIDR-C4 N 1:114 * 199.1.254/23 NETBLK-SPRINT-BLKA N 1:1800 2:1240 * 199.44.0/17 NETBLK-CMDS-TLH N 1:1800 2:1240 This list is grep'd from the new report "nets.non-classful" available from nic.merit.edu:/nsfnet/announced.networks . --Dale > From list-admin Wed Mar 9 13:50:45 1994 > To: regional-techs(a)merit.edu > Subject: CIDR in the Internet > > Folks, > It is my understanding that Feb 15 was the date when > we'll start using CIDR capabilities by keeping aggregates, > and not propagating individual network numbers. What is the > current status on this ? Are we doing this now ? And if not, > then do we have a new schedule for doing this ? > Yakov >

1 0

Re: CIDR in the Internet
by Jessica Yu 09 Mar '94

09 Mar '94

Yakov: Below are some aggregate routes known to NSF/ANSnet backbone currently. There are more aggregate routes have been configured to be advertise to the BB. CIDR routes in Ann Arbor ENSS's routing table: 193.157.64 140.222.41.2 UG (0)0 ffff e000 199.1.254 140.222.41.2 UG (0)0 ffff fe00 198.66 140.222.41.2 UG (0)0 ffff 8000 There are also other live CIDR routes exists in other NSP's routing table. The prefixes are announced to the bgpd mailing list by the NSPs. --jessica ------- Forwarded Message Return-Path: list-admin Received: from watson.ibm.com (watson.ibm.com [129.34.139.4]) by merit.edu (8.6.5/8.6.5) with SMTP id NAA27233 for <regional-techs(a)merit.edu>; Wed, 9 Mar 1994 13:49:39 -0500 From: yakov(a)watson.ibm.com Message-Id: <199403091849.NAA27233(a)merit.edu> Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 5929; Wed, 09 Mar 94 13:49:39 EST Date: Wed, 9 Mar 94 13:49:39 EST To: regional-techs(a)merit.edu Subject: CIDR in the Internet Folks, It is my understanding that Feb 15 was the date when we'll start using CIDR capabilities by keeping aggregates, and not propagating individual network numbers. What is the current status on this ? Are we doing this now ? And if not, then do we have a new schedule for doing this ? Yakov ------- End of Forwarded Message

1 0

CIDR in the Internet
by yakov＠watson.ibm.com 09 Mar '94

09 Mar '94

Folks, It is my understanding that Feb 15 was the date when we'll start using CIDR capabilities by keeping aggregates, and not propagating individual network numbers. What is the current status on this ? Are we doing this now ? And if not, then do we have a new schedule for doing this ? Yakov

1 0

Invitation to Network Providers
by Elise Gerich 09 Mar '94

09 Mar '94

This may be of interest to some of the folks on this list. I received the copy of this message from Frode Greisen. If you are interested in pursuing this, please contact Bill Baker directly. If not just toss it and move on. --Elise -------------------------forwarded message------------------ Date: Sat, 5 Feb 94 11:51:02 PST From: Bill Baker <bbaker(a)calsoft.com> To: frode.greisen(a)uni-c.dk Subject: Network Providers Proposal Frode Greisen European Backbone Network Dear Frode, Let me introduce myself. My name is Bill Baker and I'm president of California Software. For the last year, our company has been developing a Microsoft Windows based InterNet product. Over the course of developing this product several issues concerning Network Providers have arisen. Enclosed is a proposal that I would like to discuss with you or whomever in you organization you feel would be appropriate. It is California Software's desire to create a relationship with a number of network providers and work toward an industry standard that might ease the difficulties related to configuring dial up SLIP or PPP connection into the Internet. We are in full development at this time on a comprehensive software program that we hope will provide the most up to date multi-media communication products as well as being truly "plug and play". I look forward to discussing this further with you and your staff. You may contact me directly by phone or electronically at bbaker(a)calsoft.com Sincerely, Bill Baker, President California Software, Inc. 2121 East Pacific Coast Hwy. Suite 120C Corona del Mar, California 92625 714-729-4224 USA ___________________________________________________________________ A Solution for Network Providers Standards Today there are many companies working on PC products for Internet connectivity. These same products are also being developed for a variety of other platforms, by both network providers and by independent software vendors (ISVs). Various approaches are being taken in developing these products. At one end of the spectrum, legacy networks like CompuServe and AOL are basing their Internet services on mainframe-based application relays which will give existing users access to conventional Internet services like Archie and Gopher. Internet-centric network providers and ISVs such as NetManage, Spry, and California Software, are working on software that provides "full membership" in the Internet by providing the end user with a TCP/IP link for unlimited access to a variety of services and protocols. We believe that in the long run, this "full membership" Internet access will prevail to become the dominant method for Internet access. Today there are two major technical barriers to "full membership" Internet connection. First is the lack of robustness of the SLIP protocol. PPP is much improved. Second is the extraordinary difficulty, for the typical user, of configuring and bringing up either a SLIP or PPP connection. The question is, can PC software be designed which will effortlessly connect a user to any network provider and provide full Internet connectivity without the personal involvement of the network provider's support staff? We have observed users attempting to bring up SLIP and PPP connections with off-the-shelf networking products and have concluded that using current methods such connections will almost always fail on the first attempt. This usually results in support calls to the network provider, the software vendor, or both. If automatic-configuring software existed the technical support for both the network provider as well as the creator of the software would be drastically reduced. There is no argument that the majority of all technical support efforts which are a direct expense to either the software developer or network provider occur in the first few hours of operation. With this in mind California Software Inc. (CSI) is building into its product automatic configuration code to deal with this issue. With the cooperative effort of both the network provider and software suppliers like CSI, we believe significant savings can be realized. Technical support workloads will be reduced, but more importantly both companies will have satisfied customers and will be looked at as industry leaders with the most advanced products that are useful for users at every level. Difficulty There are two significant stumbling blocks to configuring and managing a SLIP/PPP connection. When a user subscribes to a provider's emulator service, he has only three parameters to manage: the POP telephone number, his User ID, and his Password. The user attempting to bring up a SLIP/PPP connection must manage these three parameters plus at least ten others including Internet addresses for himself, a gateway, an SMTP server, domain name servers, and NNTP servers. Depending on the service, he may also have additional User ID's, passwords, and telephone numbers to cope with. Making matters worse, the establishment of a SLIP/PPP connection requires a negotiated dialog between the user's PC and the service provider's POP controller. This is not standardized and varies from provider to provider. A connection script that works must be tailored to the specific provider. Because of this complexity, the probability of a SLIP/PPP connection working the first time approaches zero. We have never seen such a connection work on its initial attempt. This is guaranteed to be a trying experience for the user and a very expensive customer support challenge for the network provider. Proposed Solution California Software's new product line will incorporate several facilities specifically for simplifying TCP/IP and SLIP/PPP configuration and management. This section describes these. 1. Central Network Data Repository In many competitive products we find that a particular network parameter may appear many times in different places. Typically each network sub-application has a configuration panel in which the user is required to enter his IP address, a target IP address such as the service's SMTP server, and the ever mysterious "subnet mask". CSI's program will have only one place in which this information is stored for all of its sub-applications in a local SLIP.INI file. 2. Parsable SLIP/PPP Parameter List When a user orders a SLIP or PPP connection from a network provider today, he receives a list of 10 to 15 parameters needed for the connection from the provider's network operations center (NOC). This can be in the form of a telephone call, or more typically, embedded in a computer-generated e-mail letter sent to the user's emulator account. The user must understand the meaning of the parameters, find out where they need to be put, and accurately hand copy the numeric IP addresses and other items into his network software. He must obtain all this information typically using a very unfriendly UNIX mail application. We intend to work with Internet network providers to encourage them to adopt an easily parsed standard SLIP.INI document. After a customer orders a SLIP or PPP connection the SLIP.INI document can be placed in the root of his emulator account (this avoids sending user ID's and passwords via e-mail). Our program's automatic configuration process will extract information from the SLIP.INI document to use in configuring the SLIP/PPP connection without user intervention. A copy of a proposed format for the service provider's SLIP.INI file is included as an attachment to this document. Putting the SLIP/PPP access parameters into the proposed SLIP.INI format is a small task (a few hours) for the majority of network providers, who already computer-generate e-mail containing this same information in a form letter. We will supply a parsing macro to extract information from the proposed SLIP.INI format. For those network providers who are not willing to adopt this format we will write parsers to extract configuration information from their e-mail SLIP/PPP letters, but this procedure is open to risk because our automated configuration procedure may fail if a network provider changes the format of its standard letter. 3. Automatic Configuration Once the network parameters are obtained by reading a SLIP.INI document, parsing an e-mail message, or entered by hand into a single dialog box, CSI's software will automatically configure the system. This configuration process includes updating the user's local SLIP.INI file with the new network parameters and propagating parameters to the program's sub-applications as needed. The software program will also obtain, or alternatively ask for, the name of the network provider and/or the brand of the communications server used at the network provider's POP (typically CISCO, Livingston, Emulex, or other hardware). This will enable CSI's program to construct the brief but critical connect-time SLIP/PPP negotiation macro used for initializing the network connection and in some cases, for obtaining the user's dynamic IP address assigned at connect time by some network providers. 4. 911 Log CSI's products incorporate a 911 log which is a running log of warning and error messages which are produced by the program, and which can be used for remote diagnosis purposes. The log is a repository for all of the program's error messages. It is designed as a LIFO stack that can be interrogated remotely by technical support. 5. Network Provider Log in Selection Network providers that are willing to participate with CSI and adhere to a workable standard will be integrated into the automatic software setup process. Customers who do not currently have a network provider or who need to choose a provider will be given at installation time the opportunity to choose service from the CSI's list of "cooperating" providers. This process will probably work from a zip code search, which will make available on screen those providers that have point of presence within local calling distance of the customer. We believe that by incorporating these techniques we will be able to significantly increase the chances the user will be able to establish a SLIP/PPP connection without the need for expensive, professional assistance. The reduction of support costs to the network provider supplies the necessary quid quo pro for adopting the standard SLIP.INI format, as well as for an open standard to be used by other network software vendors. Following is an example of a proposed format and contents for a service provider's SLIP.INI document. Network Providers' SLIP.INI Format Example [Service] Provider=NETCOM NOCMail=noc(a)netcom.com CSMail=support(a)netcom.com VoicePhone=4085548717 [Software] Provider=CSI CSMail=support(a)calsoft.com VoicePhone=7147294223 FAXLine=7146446277 [Dial IP] Protocol=PPP Compression=yes DynamicIP=no DefaultDomainName=smerz.slip.netcom.com UserID=Smerz Password=adioW34 IPAddress=192.187.11.4 PhoneNumber=4083388765 MaxSpeed=14.4 DefaultGatewayIP=192.187.54.56 POPNode="Livingston 2000" CustomDomainName=slg.com [Emulator IP] ConnectionType=VT100 UserID=merz Password=atrn65grB PhoneNumber=4083386432,7148760034 MaxSpeed=9.6 BinXfrMode=zmodem [POP3] DomainName=netcom.com IPAddress=192.100.81.105 [SMTP] DomainName=netcom.com IPAddress=192.100.81.105 [NNTP] DomainName=nntp.netcom.com IPAddress=192.100.81.105 [DNS] IPAddress=192.100.81.101,192.100.81.101

1 0