From: bacameron@amoco.com (B. Cameron) Date: Fri, 22 Apr 94 10:13:43 CDT To: nexus-gaia@netcom.com Subject: Sprint Customer Handbook More info... yippi Brian bacameron@amoco.com --(cut here)-- From: daemon@sprintlink.net Date: Fri, 22 Apr 94 11:09:39 -0500 To: bacameron@chi.amoco.com Subject: Re: Customer Handbook request >Please send me a copy of your Customer Handbook. Thanks much. >Brian Cameron >bacameron@amoco.com SprintLink Customer Handbook Table of Contents 1.0 Introduction 2.0 SprintLink Description 3.0 Administration 3.1 Ordering Service 3.1.1 OFDC 3.1.2 Interface Schedule 3.1.3 Customer Internet Information Form 3.2 Routing Changes 3.3 DNS Changes 4.0 Intervals 5.0 NSFNET-Related Issues 6.0 Registrations 6.1 IP Address 6.2 Domains 6.3 Autonomous System Number 6.4 IN-ADDR.ARPA 6.5 WHOIS 6.6 News Registration 7.0 Trouble Management 7.1 Trouble Management Overview 7.2 Escalation APPENDIX APPENDIX A: The NSFNET Backbone Services Acceptable Use Policy APPENDIX B: Internet Changes and Issues APPENDIX C: Configuration Request Template APPENDIX D: Internet Number Template APPENDIX E: Internet Domain Registration APPENDIX F: Autonomous System Number APPENDIX G: IN-ADDR.ARPA Registration APPENDIX H: Internic WHOIS Registration 1.0 Introduction This Handbook contains the information necessary for SprintLink customers to properly establish Internet connectivity, submit changes, and resolve troubles. Distribution of this document is limited to customers and prospective customers. Any comments or suggestions for improvement should be sent to Patricia Kendall (Internet: Patricia.A.Kendall@sprint.sprint.com or SprintMail: P.Kendall). 2.0 SprintLink Description The SprintLink Public Data Internet provides users and peer networks throughout the world a variety of services. For users, SprintLink provides access to the global Internet. For peer networks, SprintLink provides transit to other peer networks and access to SprintLink customers. A user is defined as a firm, institution or individual. A peer network is a network which provides public service to users. Examples of peer networks include Alternet, ANS, Morenet (Missouri), and WESTnet. The interconnection topology and procedures of the thousands of networks that comprise the Internet throughout the world is very complex and unfortunately impacts all users. SprintLink shields the user from much of the complexity. The following briefly describes Sprint's Internet infrastructure. An understanding of Sprint's Internet services architecture and how it relates to the balance of the Internet is useful and will facilitate relations between Sprint and the customer. Sprint operates four Internet networks: International Connections Manager Network (ICMnet)- Atlantic, ICMnet-Pacific, ICMnet-Moscow and SprintLink. The ICMnets provide international routing services under a cooperative agreement with the US National Science Foundation (NSF) for US R&E and government international connectivity, several commercial US Internet service providers and likewise for several foreign national networks. The combination of these four networks yields an infrastructure that has become the routing "core" of the global Internet. The following describes each Sprint network. ICMnet-Atlantic ICMnet-Atlantic, Internet Autonomous System Number (ASN) 1800, currently provides routing service between the US Internet and the European Backbone (EBONE). There are four interconnection points in the UK, France, Germany and Sweden. ICMnet-Atlantic also interconnects with national networks in South Africa, Kuwait, Turkey, India and Costa Rica and Ecuador. It also interconnects with ICMnet-Moscow which in turn connects to the embryonic Russian Internet. Peru, United Arab Emirates and several national networks in Latin America will be connected in 3Q93. ICMnet-Atlantic connects to NSFnet and to other Federal Networks, e.g., NASA Science Internet, Energy Sciences Network, MILnet, etc. at the Federal Internet Exchange in College Park, Maryland. ICMnet-Atlantic is also connected to the Washington DC Metropolitan Area Ethernet (MAE-East) where it connects with Alternet, PSInet and SURAnet over a 10 mbps ethernet provided by metropolitan Fiber Systems (MFS). ICMnet-Atlantic routing to Europe is coordinated with the European Backbone (EBONE) which is a cooperative effort among several European national networks. ICMnet-Atlantic obtains trans Atlantic back-up from Alternet/EUnet and ANS/EASInet. ICMnet-Atlantic interconnects with the SprintLink Public Data Internet in Washington, DC ICMnet-Pacific ICMnet-Pacific, Internet ASN 1240, currently provides routing service between the US Internet and National Center for Science Information Systems (NACSIS) in Japan. We plan to establish connections to China, Indonesia, Philippines and other Japanese networks in 1994. ICMnet-Pacific connects to NSFNet and to other Federal Networks at the FIX-West at NASA Ames in California. Most nations in Pacific Rim are available via this path into PACCOM (Korea, Hong Kong, Japan, Australia and New Zealand). ICMnet-Pacific also interconnects with SprintLink. ICMnet-Moscow ICMnet Moscow, Internet ASN1803, provides direct access to the US internet. It was established in June of 1993. SprintLink SprintLink, Internet (ASN 1239), is Sprint's commercial Public Data Internet. SprintLink connects to both ICM-Atlantic and ICM-Pacific, the Commercial Internet exchange (CIX) and the Metropolitan Area Ethernet East (MAE-East) in Washington, DC. At the CIX routes are exchanged with Alternet, PSInet, CERFnet, ANSnet (MCI/IBM), BARRnet, NEARnet, JVCnet, WESTnet, Nordframe (Finland), EUnet (Europe) and UK PIPEX. at MAE-East SprintLink interconnects with Alternet, PSInet, SURAnet and ANSnet. SprintLink also interconnects with several Regional and State peer networks. SprintLink is a fully meshed network of T1s connecting the backbone's four node sites. Some links have multiple T1s and there is one DS3 (45 mbps) link. Backbone capacity (link and router) is continuously monitored and capacity is added when necessary SprintLink provides Network News and Network Information Service Center (NISC) facilities which are described in Appendix C. SprintLink provides primary Domain Name Service (DNS) for customers purchasing this service. SprintLink provides secondary DNS for all SprintLink customers. Nationwide dial-up service deployment is underway for specific customers. Full scale dial-up product availability is planned for 1Q94. SprintLink is directly connected to national networks in Malaysia, Japan, India, and the UK (bypassing the ICMnets) and provides them international routing services. Foreign networks connect to SprintLink if they do not wish their USA transit to be provided by the NSFnet. SprintLink and ICMnet routers are collocated at Sprint Technical Office Centers (TOCs) where they receive local support from Sprint Technicians as well as power and access to Sprint transport facilities, i.e., private line, frame relay and X.25 The TOCs housing SprintLink /ICMnet routers are Washington, D.C., Stockton, California, Chicago, Illinois and Fort Worth, Texas. ICMnet routers are also located at the FIXes and several overseas sites (but they are not SprintLink points of Presence). The routers in the TOCs are interconnected by FDDI concentrators thus providing 10 mbps inter TOC connectivity. Below are notable SprintLink Facts: Netname:SPRINTLINK Netnumber: 144.228.0.0 Coordinator: Ken Albanese albanese@icm1.icp.net (703) 904-2000 Domain System Inverse Mapping Provided by: OPS.SprintLink.net 192.94.207.70 ICM2.icp.net 192.80.214.224 Sprint.Net (SprintLink-Dom) 13221 Woodland Park Road Herndon, Virginia 22071 Domain Name: SprintLink.Net Administrative Contact: Steve Burkes sburke@icm1.icp.net Technical Contact, Zone Contact: Ken Albanese albanese@icm1.icp.net Domain Servers Listed In Order: Ops.SprintLink.net 192.94.207.70 icm1.icp.net 192.94.207.66 icm2.icp.net 192.80.214.224 3.0 Administration For the customer to receive a useful service there are several administrative functions that must be coordinated between the customer and SprintLink., such as, Order Service, Making Changes to an Order, Routing changes and DNS changes. 3.1 Ordering Service Your Sprint Account Team will work with you to complete a SprintLink Order form for Data Communications (OFDC), Interface Schedule, and a Customer Internet Information Form. One OFDC is required per customer site. The OFDC is used for recording high-level customer information such as the customer's name and billing address as well as a general description of the service being ordered. The Interface Schedule describes the transport services required of Sprint. The Customer Internet Information form solicits parameters and information pertaining to the customer's internet environment that the SprintLink network must accommodate in order to provide a useful Internet access service. 3.1.1 OFDC %OFDC fields include: %Customer Number %Customer Name %Date %Billing Address %Sales Office Log %Customer Contracts Contact Name %Customer Contracts Phone %Billing Contact %Billing Phone additional Information %Customer Signature %Sprint Signature %Agreement Number %Type of Service %New Customer %Add On %Upgrade %Downgrade %Move disconnect %Cancel Before Start %Software Change %Renewal %Term Conversion %Billing Change Sales Tax Exemption Status Customer Request Date NPA-NXX Peering Point IP Address Access Type T-1 DDS ITAP Frame Relay Quantity 3.1.2 Interface Schedule An Interface Schedule must also be completed for each customer connection to SprintLink. The Interface Schedule defines the technical description of the physical level services providing the customer site connectivity to a SprintLink router node. The account team may need to work with the customer to obtain the following information: For a New SprintLink Order: City, State and Zip of customer Whether the location is new or existing City and state name for location of access line Floor/Room/Endpoint device Floor/Room/Telco demarc Street address, city , state and Zip Site contact person's name Site contact person's phone number What type of access: T1, ITAP, Frame Relay or 56 DDs Additionally for Access If Ordering Required Information T-1 B8ZS/ESF or AMi/SF ITAP T-1 For New Access Channel on Existing ITAP The FMS Number of the Existing ITAP The Number of timelsots to be used The Timeslots which will be used The access channel speed The type of CPE to be used and whether it is customer or Sprint provided For New ITAP T1 Orders Whether you are Ordering ESF/B8ZS, ESF/AMI, or D4/AMI The CPE to be used and whether it is customer provided 56DDS Whether the DSU is Sprint or customer Provided The DSU type The type of CPE Frame Relay Whether the DSU is Sprint or customer provided The DSU Type The type of CPE DLCI Number 3.1.3 Customer Internet Information Form The customer will be asked to provide the following information. It is not absolutely necessary to provide this information at order submittal time; but it is required at least one month before service activation. %Customer contact as described in the INTERNIC WHOIS (RS.INTERNIC.NET) %WHOIS e-mail customer contact %Telephone %Home Telephone %FAXNumber %E-Mail %Page %Cellular %Operations Manager %Systems Administrator %Administrative Manager %Principal Period of Maintenance (PPM) contact procedures %Outside of PPM contact procedures %Well known customer-site hosts: %Host Name %Address %Purpose %Password control requirements %Customer routing protocols %Router-based firewall requirements %Customer domain %Primary DNS Requirements %Current name servers %Zone file contents Secondary DNS Requirements Current Name servers Customer in-addr.arpa requirements Current Name servers Zone File Contents Secondary in-addr.arpa n-addr.arpa requirements Current in-addr.arpa domains Reporting requirements Reporting is an optional feature which describes on a monthly basis customer link utilization and availability. 3.2 Routing Changes Routing changes, i.e. a new customer network, must be submitted using the Network Announcement Change Required (NACR) template provided in Appendix C. Routing changes should be sent via e-mail to nacr@icm1.icp.net 3.3 DNS Changes DNS changes i.e., a network name, must be submitted to dns-admin.icp.net. 4.0 Intervals New domestic orders will be implemented in 60 days. Non domestic orders will be implemented in 90 days subject to cooperation from the foreign PTT. 5.0 NSFNET-Related Issues The NSFnet provides transit routing services to regional networks including BARRnet, CERFnet, CICnet, JVCnet, MIDnet, NEARnet, NorthWestNet, Nysernet, PREPnet SESQUInet, SURAnet and WESTnet. NSFnet also interconnects with ICMnet-Atlantic (Sprint) ICMnet-Pacific (Sprint), Alternet, CA*net (Canada) and Monterey Technet (Mexico). NSFnet will only allow traffic meeting the NSFnet appropriate use policy (AUP ) described in Appendix A. As discussed earlier, several of these regionals connect to the Commercial Internet exchange (CIX). For those that do connect to the CIX there are, of course, no restrictions on the type of traffic that can be transmitted and received. Regionals that exclusively connect to the NSFnet backbone can only send and receive traffic that meets the NSFnet AUP. If the SprintLink customer meets the AUP then SprintLink will announce the customer's network(s) to the ICMnets for transit to the NSFnet. For Sprint to do so, the customer must adhere to the instructions and procedures specified in Appendix C, Network Announcement Change request (NACR). It should be noted that in mid 1994 the NSFNet will no longer exist. It will be decommissioned and Regional l networks must obtain Internet access from commercial service providers such as Sprint. Sprint is aggressively seeking direct internconnection with both Regional and State networks (bypassing the Regional) to assure the best connectivity to all components of the US internet. Regardless of how successful Sprint is in connecting directly with State and Regional networks we will always have a connectivity path available for SprintLink customers through Sprintlink's interconnection with the CIX, MAE-East and NSF-planned network Access points (NSF-sponsored interconnection points where Regional, national, commercial, federal and R&E networks can freely interconnect. 6.0 Registrations The Internet is by far the most complex and useful data communications system in the world. It's success is due to its decentralized nature. However, there are several coordinating functions that must be adhered to. As such, the US government funds the INTERNIC which coordinates Internet address and name space management as well as maintain Internet data. The following describes several registration actions that may have to be taken for the customer's network to be interoperable with SprintLink and the Internet. 6.1 IP Address Appendix D, Internet Number Template describes the process for obtaining an Internet address. When Classless Interdomain Routing (CIDR) begins in the late Fall of 1993, SprintLink will begin assigning customers IP addresses in accordance with Internet Activities Board guidance. It is anticipated that customers will have IP address "portability." 6.2 Domains Appendix E, Internet Domain Registration, describes the process for obtaining an Internet domain. Domain registration forms may be retrieved via ftp from ftp.SprintLink in the networking directory or via e-mail to hostmaster @icp.net. 6.3 Autonomous system number Appendix F, Autonomous System Number Registration describes the process for obtaining an Internet Autonomous System Number (ASN). An ASN is only necessary when the customer wishes to "peer" with SprintLink. 6.4 IN-ADDR.ARPA Appendix G, IN-ADDR.ARPA Registration, describes the process for the customer to register "reverse" name service, i.e., mapping IP Addresses to names. In- ADDR.ARPA registration must be submitted to inaddr@icp.net. 6.5 WHOIS The INTERNIC maintains a WHOIS database that is accessible through the Internet. It includes information on virtually every element of the global Internet infrastructure. A key element of WHOIS is the identification of individuals who are key in operating components of the Internet. Appendix H, INTERNIC WHOIS REGISTRATION describes the process for registering key individuals in the WHOIS database. The INTERNIC WHOIS database can be reached via telnet to RS.INTERNIC.NET. 6.6 Network News 7.0 Trouble Management 7.1 Trouble Management Overview Sprint operates a Customer Service Center (CSC) to resolve network service difficulties. If customers have trouble with their network service they should call the SMC (800-726-0201). The SMC operator will record the nature of the problem and open a trouble ticket which is routed to the Sprint Integrated Network Management Center (INMC). The INMC monitors and manages Sprint's public and private internet networks as well as many other network management centers associated with Sprint's customer services and other private network including FTS-2000. THE INMC is operated on a 24 hour per 7 day per week basis. Once a trouble ticket has been opened, an e-mail message is sent by the INMC to the customer contact mailing list. Peer transit networks should call directly into the INMC. Telephone: 800-669-8302 703-904-2288 FAX: 703-904-2262 Troubles may be reported by e-mail to inmc@icm1.icp.net 7.2 Escalation The following escalation guidelines apply for Sprintlink related problems: Elapsed Time Action Begin: Customer calls Sprint's SMC (800-726-0201) and reports a problem related to "Sprintlink Service." The customer will be asked to provide specific information needed to open a trouble ticket, such as an account number or private number for Clearline customers, or network address for Frame Relay and X.25 customers. This information is provided to each customer when the service is first activated. A trouble ticket will be opened by the SMC operator and passed on to the INCM even if the customer is not able to supply all the basic information, but the initial research may slow down the resolution process. 2 Hours When necessary, troubles will be escalated to the INMC supervisor level. A customer may call and request this escalation (800-726-0201). 4 Hours: A 2nd level escalation may be requested by dialing 800-726-0201. 6 Hours The INMC Manager is the 3rd level of escalation chain: Paul Pepe (703-904-2322) Pager: 800-859-7242 PIN:18918 e-mail:Pepe@sprint.sprint.com 24 Hours The Director of Network Services is the 4th level of escalation: Bob Becker (703-904-2090 e-mail:Becker@sprint.sprint.com NOTE: A notification message will be issued upon the opening of a trouble ticket and at each escalation step, addressed to the customer representative(s) on file, to the appropriate Sprint account team, to the SprintLink program manager, Steve Burkes, and to the director of Internet Services and Systems, Bob Collet. SprintLink Program, Manager: Steve Burkes (703)-904-2357 Pager-703-701-4170 email: steve.r.burkes@sprintintl.sprint.com ISS Program Director: Robert Collet (703)904-2230) Pager: 800-759-7243 Pin 45469 email:robert.d.collet@sprint.sprint.com APPENDIX A: The NSFNET Backbone Services Acceptable Use Policy General Principle: 1. NSFnet backbone services are provided to support open research and education in and among US research and instructional institutions, plus research arms of for-profit firms when engaged in open scholarly communication and research. Use for other purposes is not acceptable. Specifically acceptable uses: 2. Communication with foreign researchers and educators in connection with research or instruction, as long as any network that foreign user employs for such communication provides reciprocal access to US researchers and educators. 3 Communication and exchange for professional development, to maintain currency, or debate issues in a field or subfield of knowledge. 4. Use for disciplinary-society, university-association, government- advisory, or standard activities related to the user's research and instruction activities. 5. Use in applying for or administering grants or contracts for research or instruction, but not for other fund raising or public relations activities. 6. Any other administrative communications or activities in direct support of research and instruction. 7. Announcements of new products or services for use in research or instruction, but not advertising of any kind. 8. Any traffic originating from a network of another member agency of the Federal Networking Council if the traffic meets the acceptable use policy of that agency. 9. Communication incidental to otherwise acceptable use, except for illegal or specifically unacceptable use. UNACCEPTABLE USES: 10 Use for-profit activities, unless covered by the General Principle or specifically acceptable use. 11. Extensive use for private or personal business. This statement applies to use of the NSFNET backbone only. NSF expects that connecting networks will formulate their own use policies. The NSF Division of Networking and Communications Research and Infrastructure will resolve any questions about this Policy or its interpretation. Appendix B Internet Changes and Issues It should be noted that the nature of global routing is undergoing major changes. With the Internet growing at such a high rate, the routing technology and associated management expertise to support a flat topology, i.e, hierarchy is rapidly reaching a crisis point. consequently, two actions are planned by the Internet: formation of a Global Internet exchange (GIX) and adoption of Classless Interdomain Routing (CIDR) routing. The GIX point will be a hierarchical high point in global routing and minimize the need for complex transit associated peering relationships for most of the world's networks. Intelligence at the GIX, i.e., a route server, will minimize the burden on global transit networks when they seek routing information. The route server minimizes the need for pair-wise peering. The Coordinating Committee for Intercontinental Research Networking (CCIRN) Intercontinental Engineering Planning Group (IEPG) has designated the Metropolitan Area Ethernet - East (MAE-East) as the first GIX point. Sprint, Alternet, PSInet, SURAnet and ANS are MAE-East members. CIDR provides a mechanism for route aggregation and consequently reduces the size and complexity of routing tables Current routing technology will be insufficient to support switches with the need to have full knowledge of all routes in the world. Aggregation i.e., hierarchy, eliminates the need for having to know all routes. All router manufacturers who sell to large public transit networks will need to support the required protocols (BGP-4) so that CIDR can be implemented. APPENDIX C: Configuration Request Template Index: 1.0 General Instructions and Policies 1.1 Configuration Instructions 1.2 Template Instructions 2.0 NACR Template 3.0 Explanation of Specific Fields in the Template 4.0 Examples 5.0 Carnegie Classification Codes 2.0 NACR Template The Following template includes the Sprint Applied Technology Center as an example to indicate the fields. Network Announcement Change Request The administrators of the following networks for which access is requested to the NSFNET backbone service agree that traffic from these networks that will transit NSFNET backbone service complies with the "NSFNET BACKBONE SERVICES ACCEPTABLE POLICY" Dated June 1992. %begin nsfnet nacr v7.0 #Any entry must look like: netnum: 192.207.217 netname: net-sprintatc1 netcc: US orgname: Sprint Applied Technology Center orgaddr: 3065 Cumberland Circle orgcity: Atlanta orgstate: GA orgzip: 30339 orgcc: US orgtype: C bbone: T3 homeas: 1239 aslist: Sprint will fill in this section aup: N action: A comment: Coordinator is Ron Reynolds, 404-859-7315 # any other entry.... %end nsfnet nacr 3.0 Explanation of Specific Fields in the Template netnum: Network IP Address The IP address of the network, in dot-notation, with or without the trailing 0'. Mandatory netname: Network Official Name The official name of the network, as it is registered with the InterNIC WHOIS database, should appear on this input line. Mandatory netcc: Network Country Code. This is the country where the network is located (vs. the organization that is responsible for the net) If the net spa ns multiple countries please try to pick the one which you feel best represents the net. The country code requested on this line must comply with the two letter ISO 3166 codes. A listing of these codes may be ftp'd from nic.merit.edu.nsfnet/announced.networks/country.codes. mandatory. orgname: Organization responsible for network The name of the organization to which the network belongs should be listed under this section Mandatory. orgaddr: Organization Address. The address of the organization. Mandatory orgcity: City of the organization The city the organization is located in Mandatory for US addresses orgstate: State of the organization The state or province the organization is located in Mandatory for US addresses orgzip: ZIP code ZIP code or postal code of the organization location Mandatory for US addresses orgcc: Organization Country Code The country code of the organization. It should comply with the two letter ISO codes. Mandatory orgtype: Type of organization or education organization type. The classifications are intended to describe the organizations' general focus. Intended use of the network is not at issue here, as that is covered by the Acceptable Use Policy to which it adheres: c(COM) - Companies, including nonprofit corporations g(GOV) - Nonmilitary city, state, and federal government agencies m(MIL) - Military organizations e(EDU) - Educational Institution. Please choose from the codes listed in section 5. below. Complete definitions and a list of most US colleges and universities is available on nic.merit.edu.nsfnet/announced.networks/org.types If none of these codes are appropriate, please use EDU as the organization type n(NET) - Internet access providers that sell network connections o(ORG) - Organizations, such as CNI (Coalition for Networked Information) and FARNET (Federation of American Research Networks) Mandatory bbone: bbone The backbone to use. Must be T3 Optional homeas: The original ASN Number for this network Autonomous Systems the network belongs to. This will often be an AS that does directly peer with NSNFnet. Mandatory aslist: Inbound Announcements to NSFnet This input line(s) will be filled out by Sprint and will specify which Sprint Autonomous System number (ASN 1800 or ANS 1240) that will announce the network) THE ASNs will be listed in order of preference, with the most highly preferred listed first). The preference will generally be a function of geography i.e., customer networks east of the Mississippi will have 1800/12340 and those west of the Mississippi will have 240/1800. Mandatory. aup: Acceptable Use Policy N: NSFnet AUP The customer agrees that the traffic sent to destinations reachable only via the NSF meets the NSFNET AUP. Sprint is a member of the Commercial Internet Exchange, Metropolitan Ethernet-East (MAE-East) and is directly connected to Regional and State Networks. All Regionals have connectivity to either the CIX or MAE-E. Regional s will not "announce" purely R&E (NSFNET AUP) networks to the CIX, only the NSFNET. action: Action being requested ( A/D/C) This line must indicate if the inbound announcements you are requesting for this network will b e a change to existing inbound announcements to the NSFNET (C), a complete deletion of all inbound announcements to the NSFNET (D), or if this request is to add a network that is not currently being announced to the NSFNET (A). Comment: Comments Comments Lines Optional 4.0 Examples Example 1: Single Net Suppose network 192.207.217 (net-sprintatc1), wishes to be announced to the NSF This is an addition request. Their Network Announcement Change Request to Sprint follows: Network Announcement Change Request The administrators of the following networks for which access is requested to the NSFNET backbone service, agree that traffic from these networks that will transit the NSFNET backbone service complies with the "NSFNET BACKBONE SERVICES ACCEPTABLE USE POLICY" Dated June 1992. % begin nsfnet nacr v7.0 netnum: 192.207.217 netname: net-sprintatc1 netcc: US orgname: Sprint Applied Technology Center orgaddr: 3065 Cumberland Circle orgcity: Atlanta orgstate: GA orgzip: 30339 orgcc: US orgtype: C bbone: T3 homeas: 1239 aup: N action: A comment: Coordinator is Ronald Reynolds, 404-859-7315 netnum: 192.207.218 netname: sprintatc2 netnum: 192.207.219 netname: sprintatc3 %end nsfnet nacr Given the networks are in Atlanta, Sprint will route sprintatc1, sprintatc2 and sprintatc3 to NSFNET via AS1800 as Priority 1 and via AS1800 as priority 2. Example 3: Multiple nets, same organization, Differing Inbound Announcements, same country locations Suppose network 192.207.217 (sprintatc1) 192.207.218 (sprintatc2) and 192.207 (sprintat3) wish to be announced to the NSFNET. The SprintLink customer, in this case, the Sprint Applied Technology Center, wishes to have NSFNET access diversity. After discussion with the SprintLink Implementation team, a decision is made to route sprintatc1 and sprintatc2 to the east coast (AS1800) and sprintatc3 to the west coast (AS1240). The Network Announcement Change Request to Sprint Follows: Network Announcement Change Request The administrators of the following networks for which access is requested to the NSFNET backbone service, agree that traffic from these networks that will transit the NSNFET backbone service complies with the "NSFNET Backbone Services Acceptance Use Policy" dated June 1992. %begin nsfnet nacr v7.0 netum: 192.207.217 netname: net-sprintatc1 netcc: US orgname: Sprint Applied Technology Center orgaddr: 3065 Cumberland Circle orgcity: Atlanta orgstate: GA orgzip: 30339 orgcc: US orgtype: C bbone: T3 homeas: 1239 aup: N action: A comment: Coordinator is Ronald Reynolds, 404-859-7315 netnum: 192.207.218 netname: sprintatc2 netnum: 192.207.219 netname: sprintatc3 %end nsfnet nacr SprintLink will route sprintatc1 and sprintatc2 to NSFNET via AS1800. SprintLink will route to sprintatc3 to NSFNET via AS1240. Example 4: Multiple nets, same organization, differing inbound announcements, differing country Locations Suppose network 192.207.217 (net-sprintatc1), 192.207.218 (net-sprintatc2) and 192.207.222 (net-sprintatc6) wish to be announced to the NSFNET. net- sprint and net sprintatc 2 wish to have AS1800 as their PRIORITY 1 path and AS1240 as their PRIORITY 2 path. All three nets are owned by the Sprint Applied Technology Center but netsprintatc is located in Tokyo, Japan. Their Network Announcement Change Request Follows: Network Announcement Change Request The administrators of the following networks for which access is requested to the NSFNET backbone service, agree that traffic from these networks that will transit the NSFNET backbone service complies with the "NSFNET Backbone Services Acceptable Use Policy" dated June 1992. %begin nsfnet nacr v7.0 netnum: 192.207.217 netname: net-sprintatc1 netcc: US orgname: Sprint Applied Technology Center orgaddr: 3065 Cumberland Circle orgcity: Atlanta orgstate: GA orgzip: 30339 orgcc: US orgtype: C bbone: T3 homeas: 1239 aup: N action: A comment: Coordinator is Ronald Reynolds 404-859-7315 netnum: 192.207.218 netname: net-sprintatc2 netnum: 192-41.231 netname: NBB13 netcc: JP %end nsfnet nacr SprintLink will route sprintatc1 and sprintatc2 to NSFNET via AS1800 Priority 1 AS1240 Priority 2. SprintLink will route sprintatc6 to NSFNET via AS1240 Priority 1 and AS1800 Priority 2. 5.0 Carnegie Classification Codes 2YR Two Year College ADM Administration ART Specialized: Art, Music, and Design BUS Specialized Business and Management C1 Comprehensive I C2 Comprehensive II COR Corporate College D1 Doctorate Granting I D2 Doctorate Granting II ENG Specialized Engineering and Technology HLT Specialized Other Health Profession K12 K12 School LA1 Liberal Arts I LA2 Liberal Arts II LAW Specialized Law School MED Specialized Medical School OTH Other Specialized Institution R1 Research I R2 Research II REL Specialized Religion and Theology TEA Teachers College The two non-Carnegie EDU codes have been defined as: ADM Administrative educational organizations, such as a state governing board that oversees the state's public universities K-12 Public and private education prior to college, including special education and adult education Appendix D: Internet Number Template This form must be completed as part of the application process for obtaining an Internet Protocol (IP) Network Number. To obtain an Internet number, please provide the following information on-line, via electronic mail, to HOSTMASTER@SPRINTLINK.NET. If electronic mail is not available to you, please fax to: Mr. Robert Castelli Sprint 13221 Woodland Park Road Herndon, Virginia 22071 FAX: 703-904-2252 Telephone: 703-904-2453 Attn: IP Address Request Once the INTERNIC Registration Services receive your completed application they will send you an acknowledgment, via electronic or postal mail. NOTE: This application is solely for obtaining a legitimate IP network number assignment. If you're interested in officially registering a domain please complete the domain application found in netinfo/domain-template.txt. on FTP.SprintLink. If FTP is not available to you, please contact HOSTMASTER@Sprintlink.net or phone the NIC at (800) 669.8302 or 904-2257 for further assistance. 1. If the network will be connected to the Internet, you must provide the name of the governmental sponsoring organization, and the name, title, mailing address, phone number, net mailbox, and NIC Handle (if any) of the contact person (POC) at that organization who has authorized the network connection. This person will serve as the POC for administrative and policy questions about authorization to be a part of the Internet. Examples of such sponsoring organizations are: DISA DNSO, the National Science Foundation (NSF), or similar military or government sponsors: NOTE: If the network will NOT be connected to or * routed to the US R&E/Government Internet, then you do not need to provide this information: 1a. Sponsoring Organization 1b. Contact Name: (last name, first name) 1c. Contact title 1d. Mail Address 1e. Phone 1f. Net mailbox 1g. NIC handle (if known) 2. Provide the name, title, mailing address, phone number, and organization of the technical POC. The on-line mailbox and NIC Handle (if any) of the technical POC should also be included. This is the POC for resolving technical problems associated with the network and for updating information about the network. The technical POC may also be responsible for hosts attached to this network. 2a NIC handle (if known) 2b. Technical POC name (Last name, First name) 2c. Technical POC Title 2d. Mail Address 2e. Phone 2f. Net Mailbox 3. Supply the short mnemonic name for the network (up to 12 characters). This is the name that will be used as an identifier in internet name and address tables. 3. Network Name 4. Identify the network geographic location and the responsible organization establishing the network. 4a. Postal address for main/headquarters network site. 4b. Name of Organization 5. Reserved 6. Estimate the number of the hosts that will be on the network: 6a. Initially 6b. Within one year 6c. Within two years 6d. Within five years 7. Unless a strong and convincing reason is presented, the network (if it qualifies at all) will be assigned a class C network number. Of a class C network number is not acceptable for your purposes state why. (Note: If there are plans for more than a few local networks, and more than 100 hosts, you are strongly urged to consider subnetting. (SEE RFC 9501) 7. Reason 8. Networks are characterized as being either Research, Defense, Government- NonDefense, or Commercial and the network address space is shared between these four areas. Which type is this network? 8. Type of Network 9. What is the purpose of the network? 9. Purpose For further information contact INTERNIC Registration Services: via electronic mail:` HOSTMASTER @ SprintLink.Net Via telephone: 800-669-8302 Via Postal Mail: Sprintlink Internetworking Solution 13221 Woodland Park Road Herndon, Virginia 22070 Recommended Reading (available from the NIC) Bjork, S.; Marine A., eds. Network Protocol Implementatons and Vendors Guide. Menlo Park, CA:SRI International DDN Network Information Center; 1990 August; NIC 50002 ((August 1990) 242 p. (NIC.DDN.MIL.NETINFO: VENDORS-GUIDE.DOC) Braden, R.T.; Postel, J.B. Requirements for Internet Gateways. marina de Rey, CA: University of Southern California, Information Sciences Inst; 1987 June; FRC 1009. 55 p (RS.INTERNET.NETPOLICY RFC10009.TXT) Defense Advanced Research Projects Agency, Internet Activities Board. IAB Official Protocol Standards. 1992 April; RFC 1200. 31p. (RS.INERNIC.NET POLICY RFC1200.TXT). Feinler, E.J.; Jacobsen, O.J.; Stahl, M.K.: Ward, C.A., eds. DDN Protocol Handbook Menlo Park, CA: SRI International, DDN Network Information Center; 1985 December; NIC 50004 and NIC 500006. 2749 p. Garcial-Luna-Aceves, J.J.; Stahl, M.K.; Ward, C.A., eds. Internet Protocol Handbook: The Domain Name System (DNS) Handbook. Meno Park, CA: SRI International, Network Information Systems Center; 1989 August; NIC 50007. 219 p. AD A214 698. Krikpatrick, S.; Stahl, M.K.; Recker, M. Internet Numbers Menlo Park, CA: SRI International, DDN Network Information Center ; 1990 July; RFC 1166. 182 p. (RS.INTERNIC.NET POLICY RFC1166.TXT). Mogul, J.; Postel, J.B. Internet Standard Subnetting Procedure. Standord, CA: Stanford University; 1985 August; RFC 950 18 p. (RS.INTERNIC.NETPOLICY RFC950.TXT). Postel, J.B. Internet Control Message Protocol. Marina del Rey, CA: University of Southern California, Information Sciences Inst.; 1981 September; RFC 792.21 p. (RS.INTERNIC.NET POLICY RFC792.TXT). Postel, J.B. Transmission Control Protocol. Marina del Rey, CA: University of Southern California, Information Sciences Inst; 1981. September: RFC 793.85 p (RS.INTERNIC.NET POLICY RFC793.TXT). Postel, J.B. Address Mappings. Marina del Rey, CA: University of Southern California, Information Sciences Inst; 1981 September: RFC 796.7 p. (RS.INTERNIC.NETPOLICY RFC796.TXT.) Obsolete: IEN 115 (NACC 0968-79) Postel, J.B. User Datagram Protocol. Marina del Rey, CA: University of Southern California, Information Sciences Inst; 1980 August 28: RFC 768 3 p (RS.INTERNIC.NET POLICY RFC768.TXT). Postel, J.B. Internet Protocol. Marina del Rey, CA: University of Southern California, Information Sciences Inst: 1990 March; RFC 1060. 86 p. (RS.INTERNIC.NET POLICY RFC1060. TXT). Reynolds, J.K.: Postel, J.B. Official Internet Protocols. Marina del Rey,University of Southern California, Information Sciences Inst.; 1987 May, RFC 1011. 52 p. (RS.INTERNIC.NET POLICY RFC1011.TXT). Appendix E: Internet Domain Registration To establish a domain, the following information must be sent to the INTERNIC Domain Registrar (HOSTMASTER@SprintLink.Net). Questions may be addressed to the Hostmaster by electronic mail at the above address, or by phone at 703-904-2288 or (800) 669-8302. If electronic mail is not available to you, please fax to: Cornelius Healy Sprint 13221 Woodland Park Road Herndon, Virginia 22071 Fax: 703-904-2267 Telephone: 703-904-2247 Attn: DOMAIN Request NOTE: The key people must have electronic mailboxes and "handles," unique NIC database identifiers. If you have access to "WHOIS", please check to see if you are registered and if so, make sure the information is current. Include only your handle and any changes (if any) that need to be made in your entry. If you do not have access to "WHOIS:", please provide all the information indicated and a handle will be assigned. 1. The name of the top level domain to join: (EDU, COM, MIL, GOV, NET, ORG) 1. Top-level domain 2. The name of the domain (up to 12 characters). This is the name that will be used in tables and lists associating the domain with the domain server addresses. (While, from a technical standpoint, domain names can be quite long we recommend the use of shorter, more user-friendly names) 2. Complete Domain Name: 3. The name and address of the organization establishing the domain. 3a. Organization name: 3b. Organization address: 4. The date you expect the domain to be fully operational. 4. Date Operational 5. The handle of the administrative head of the organization--or this person's name, mailing address, phone number, organization, and network mailbox. This is the contact point for administrative and policy questions about the domain. In the case of a research project, this should be the principal The handle of the administrative head of the organization--or this person's name, mailing address, phone number, organization, and network mailbox. This is the contact point for administrative and policy questions about the domain. In the case of a research project, this should be the principal investigator. NOTE: Both the Administrative and the Technical/Zone contact of a domain MUST: have a network mailbox, even if the mailbox is to be within the proposed domain Administrative Contact 5a. Handle (if known) 5b. Name (last, First) 5c. Organization 5d. Mail Address 5e. Phone Number 5f Net Mailbox 6. The handle of the technical contact for the domain--or the person's name, mailing address, phone number, organization, and network mailbox. This is the contact point for problems concerning the domain or zone, as well as for updating information about the domain or zone. Technical and Zone Contact 6a. Handle (if known) 6b. Name, (Last, First) 6c. Organization 6d. Mail Address 6e. Phone Number 6f. Net Mailbox 7. Domains must provide at least two independent servers on Government- sponsored networks that provide the domain service for translating names to addresses for hosts in this domain. *If you are applying for a domain and a network number assignment simultaneously and a host on your proposed network will be used as a server for the domain you must wait until you receive your network number assignment and have given the server(s) a netaddress before sending in the domain application. Sending in the domain application without complete information in Sections 7 and 8 of the template will result in the delay of the domain registration. Also, establishing the servers in physically separate locations and on different PSNs and/or networks is strongly recommended. NOTE: All new hosts acting as servers will appear in the DNS root servers but will not appear in the HOSTS.TXT file unless otherwise requested. 5. The handle of the administrative head of the organization--or this person's name, mailing address, phone number, organization, and network mailbox. This is the contact point for administrative and policy questions about the domain. In the case of a research project, this should be the principal investigator. NOTE: Both the Administrative and the Technical/Zone contact of a domain MUST: have a network mailbox, even if the mailbox is to be within the proposed domain Administrative Contact 5a. Handle (if known) 5b. Name (last, First) 5c. Organization 5d. Mail Address 5e. Phone Number 5f Net Mailbox 6. The handle of the technical contact for the domain--or the person's name, mailing address, phone number, organization, and network mailbox. This is the contact point for problems concerning the domain or zone, as well as for updating information about the domain or zone. Technical and Zone Contact 6a. Handle (if known) 6b. Name, (Last, First) 6c. Organization 6d. Mail Address 6e. Phone Number 6f. Net Mailbox 7. Domains must provide at least two independent servers on Government- sponsored networks that provide the domain service for translating names to addresses for hosts in this domain. *If you are applying for a domain and a network number assignment simultaneously and a host on your proposed network will be used as a server for the domain you must wait until you receive your network number assignment and have given the server(s) a netaddress before sending in the domain application. Sending in the domain application without complete information in Sectons 7 and 8 of the template will result in the delay of the domain registration. Also, establishing the servers in physically separate locations and on different PSNs and/or networks is strongly recommended. NOTE: All new hosts acting as servers will appear in the DNS root servers but will not appear in the HOSTS.TXT file unless otherwise requested. Primary Server: HOSTNAME, NETADDRESS, HARDWARE, SOFTWARE 7a. Primary Server Hostname 7b. Primary Server Net address 7c. Primary Server Hardware 7d. Primary Server Software: 8. The Secondary server information 8a. Secondary Server Hostname: 8b. Secondary Server Netaddress 8c. Secondary Server Hardware 8d. Secondary Server Software: 9. If any currently registered hosts will be renamed into the new domain, please specify old hostname, net address, and new hostname. For Example: BAR-F002.XYZ.COM(26.8.0.193->F0002.BAR.COM BAR-F003.XYZ.COM (192.7.3.193)->F003.BAR.COM BAR-F004.ARPA (34.6.0.193)->F004.BAR.COM 10. Please describe your organization briefly. For example: our Corporation is a consulting organization of people working with UNIX and the C language in an electronic networking environment. It sponsors two technical conferences annually and distributes a bimonthly newsletter. For further information contact INTERNIC Registration Services: Via electronic mail: HOSTMASTER@SprintLink.Net Via Telephone: (800) 662-8302 or (703) 904-2288 Via postal mail: Network Solutions 13221 Woodland Park Road Herndon, Virginia 22071 Recommended Reading Feinler, E.J.; Jacobsen,O.J.; Stahl, M.K.; Ward, C.A. eds. DDN Protocol Handbook; Menlo Park CA:SRI International, DDN Network Information Center; 1985 December; NIC 50004 and NIC 50005 and NIC 50006. 2749 p Garcia-Luna-Aceves, J.J.: Stahl, M.K.; Ward, C.A., eds. Internet Protocol Handbook: The Domain Name System (DNS) Handbook. Menlo Park, CA: SRI International, network Information Systems Center 1989 August; 219 p. AD A214 698. Postel, J.B.; Reynolds, J.K. Domain Requirements. Marina del Rey, CA: University of Southern California, Information Sciences Inst.; 1984 October: RFC 920 14 p. (RS.INTERNIC.NETPOLICY RFC920.TXT). Harrenstein, K.: Stahl, M.K.; Feinler, E.J. DoD Internet Host Table Specification, Menlo Park, CA SRI International, DDN Network Information Center, 1985 October; RFC 952. 6 p. (RS.INTERNIC.NETPOLICY RFC952.TXT.) Obsolete RFC 810. Harrenstein, K.; Stahl, M.K. Feinler, E.J. Hostname Server. Menlo Park, CA: SRI International DDN Network Information Center; 1985 October; RFC 953. 5 p. (NIC.DDN.MIL RFC:RFC953.TXT.) Obsolete RFC 811) Partridge, C. Mail Routing and the Domain System. Cambridge, MA: BBN Labs, Inc; 1986 January: RFC 974.7 p. (RS.INTERNIC.NETPOLICY) RFC 974.TXT). Lazear, W.D. MILNET Name Domain Transition. McLean, Virginia Mitre Corporation 1987 November RFC 1031. 10 p (RS.INTERNIC.NETPOLICY RFC1031.TXT) Stahl, M.K. Domain Administrators Guide. Menlo Park, CA: SRI International, DDN Network Information Center; 1987 November; RFC 1032. 14 p (RS.INTERNIC.NETPOLICY RFC1032.TXT). Lottor, M. Domain Adminstrators Operations Guide. Menlo Park, CA:SRI International, DDN Network Information Center; 1987 November; RFC 1033 22 P (RS.INTERNIC.NET POLICY RFC 1033.TXT). Mockapetris, P. Domain Names- Concepts and Facilities. Marina del Rey, CA: University of Southern California, Information Sciences Inst; 1987 November; RFC 1034. 55 p (RS.INTERNIC.NETPOLICY RFC 1034. TXT). Updated-by: RFC 1101. Obsolete: RFC 973.RFC882, RFC 883 Mockpatetris P. Domain names-Implementation and Specification. Marina del Rey, CA: University of Southern California, Information Sciences Inst; 1987 November; RFC 1035 55 p. (RS.INTERNIC.NETPOLICY RFC 1035.TXT) Updated by RFC 1101. Obsolete:RFC 973; RFC882;RFC 883 Mockapetris P. DNS Encoding of Network Names and Other Types. Marina del Rey, CA: University of Southern California, Information Sciences Inst: 1989 April RFC 1101. 14 p. (RS.INTERNIC.NET POLICY RFC1101.TXT) Updated RFC 1034. RFC 1035. Appendix F: Autonomous System Number Registering for an Autonomous System Number implies that you plan to implement one or more gateways and use them to connect networks in the Internet. Please provide us with further details about your plans, and with information about the administrative authority you have for participating in the Internet. It is strongly advised that you follow the development of inter-autonomous systems protocols in the IAB task forces. Send the completed application on-line to HOSTMASTER@ SprintLink.net. Or, if electronic mail is not available to you, please fax to: Mr. Robert Castelli Sprint 13221 Woodland Park Road Herndon, Virginia 22071 Fax: 703-904-2252 Telephone: 703-904-2453 ATTN: ASN Request Or, mail paper copy to: Network Solutions 13221 Woodland Park Road Herndon, Virginia 22071 Questions may be addressed to the Registration Services Hostmaster by electronic mail at the above address, or by phone at (800) 444-4345 or (703) 472-4777. To obtain an Autonomous System Number the following information must be provided: NOTE: The key people must have electronic mailboxes and NIC "Handles," unique NIC database identifiers. If you have access to WHOIS, please check to see if you are registered and if so, make sure the information is current. Include only your Handle and any changes(if any) that need to be made in your entry. If you do not have access to WHOIS, or are not registered in the NIC WHOIS database, please provide all the information requested and a NIC Handle will be assigned. The name, title, mailing address, phone number and organization of the administrative head of the organization. This is the contact point for administrative and policy questions about the autonomous system. In the case of a research organization this should be the Principal Investigator. The on- line mailbox and Handle (if any) of this person should also be included. Example: Administrator Organization: Network Solutions Name: Last Name, First Name Title: Principal Investigator Mail Address: Network Solutions, Inc. 505 Huntmar Park Drive Herndon, Virginia 22090 Phone Number: (XXX) XXX-XXX Net Mailbox: pi@INTERNIC.NET Nic Handle BB34 2. The name, title, mailing address, phone number and organization of the technical contact. The on-line mailbox and NIC Handle (if any) of the technical contact should also be included. This is the contact point for problems with the autonomous system and for updating information about the autonomous system. Also, the technical contact may be held responsible for the behavior ot gateways in this autonomous system. Example: Technical Contact Organization: Network Solutions, Inc. Name: Last name, First Name Title: Computer Scientist Mail Address Network Solutions 505 Huntmar Park Drive Herndon, Virginia 22070 Phone Number: (XXX) XXX-XXXX Net Mailbox cs@INTERNIC.NET NIC Handle cc56 3. The name of the autonomous system (up to 12 characters). This is the name that will be used in tables and lists associating autonomous systems and numbers. Examples: ALPHA-BETA 4. A description of the gateway that implements the inter-autonomous system protocol for interaction with other autonomous systems. Currently the exterior gate protocol (EGP) is being used for this purpose (RFC 904). This gateway should comply with RFC 1009, Requirements for Internet Gateways. Example: This is a new gateway developed by the XYZ Group at the ABC Corporation Example: This is an instance of the well known IJK company gateway, but set up as a distinct autonomous system. 5. A Description of the gateway hardware, including CPU and interfaces. Example: DEC PDP-11/23, ARPANET Interface by ACC, Ethernet Interfaces by 3 COM. 6. A description of the gateway software, including operating system and languages. Example: The gateway is implemented using language "C" and runs Berkeley 4.2 Unix. 7 The deployment schedule for the autonomous system. a. Initially b. Within one year c. Two years, and d. Five Years Examples: a. Initially = 1 b. One Year = 3 c. Two Years = 5 d. Five Years = 10 8. What networks will be interconnected by these gateways? What are the internet addresses of each gateway? Example: One gateway, interconnecting BNET and LEWIS-PRNET2, with address 192.8.15.3 on BNET and 128.108.12.10 on LEWIS-PRNET2. For further information contact Registration Services. Via electronic mail/ HOSTMASTER@INTERNIC.NET Via telephone: 1-800-444-4345 Via Postal Mail: InterNIC Registration Services 13221 Woodland Park Road Herndon, Virginia 22071