Network Working Group Z. Wenzel Request for Comments: 2901 J. Klensin FYI: 37 R. Bush Category: Informational S. Huter Network Startup Resource Center August 2000 Guide to Administrative Procedures of the Internet Infrastructure Status of this Memo This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2000). All Rights Reserved.
AbstractThis document describes the administrative procedures for networks seeking to connect to the global Internet. This includes the steps and operations necessary for address space allocation and registration, routing database registration, and domain name registration. The document also contains information about the required forms and how to obtain them. 2 Checklist ....................................................... 3 Prerequisites ................................................... 3 I. Preparation of Systems and Network Planning ............... 4 A. What do I need to connect to the Internet? .......... 4 B. What connectivity medium should I choose? ........... 4 C. What else do I need to do? .......................... 4 D. How do I get the documents referred to in this guide? 6 E. Section References .................................. 6 II. Address Space Allocation .................................. 7 A. Who is my upstream provider? ........................ 7 B. How much address space should I ask for? ............ 8 C. What is CIDR? ....................................... 9 D. How do I request and register address space? ........ 10 E. Section References .................................. 13
III. Autonomous Systems (AS) ................................... 13 A. What is an ASN and do I need one? ................... 13 B. How do I register an ASN? ........................... 14 C. Section References .................................. 15 IV. Routing and Exchange Points ............................... 15 A. Do I need to register with a routing database? ...... 15 B. What about CIDR and routing? ........................ 16 C. How do I choose a routing database? ................. 16 D. How do I register in the RADB (The Americas)? ....... 17 E. Section References .................................. 18 V. Domain Name Registration .................................. 18 A. What is a country domain? ........................... 18 B. How do I register as a country domain? .............. 18 C. What if my country is already registered? ........... 19 D. How do I resolve a country domain name dispute? ..... 19 E. Section References .................................. 19 VI. IN-ADDR.ARPA Domain Delegation ............................ 19 A. What is an IN-ADDR.ARPA domain and do I need one? ... 20 B. How do I register an IN-ADDR.ARPA domain? ........... 20 VII. Security .................................................. 21 A. Is there a way to prevent unauthorized changes to my objects? ................................................ 21 VIII. Network Optimization and Management ....................... 22 A. How do I optimize traffic on my network? ............ 22 Security Considerations ......................................... 22 Acknowledgements ................................................ 22 References ...................................................... 22 Authors' Addresses .............................................. 24 Appendix A: The Internet Agencies .............................. 25 Appendix B: Documentation ...................................... 28 Appendix C: Country Codes ...................................... 29 Appendix D: Acronyms ........................................... 30 Full Copyright Statement ........................................ 31 Who Should Read This Document This document is intended for system engineers and technical managers of networks who want to make a connection to the Internet. It assumes a basic knowledge of the Internet and networking. This information is intended to help new or expanding networks understand and follow the Internet administrative procedures, and to provide assistance in filling out the various templates and registration forms. Appendix D is a glossary of acronyms.
Checklist This document will explain the following procedures: o Determine your organization type and current status. o Determine your administrative and technical contacts. o Determine your budget (and chargeback system) and choice of carriers. o Determine to whom you will connect. o Predict your current and projected address space needs. o Set-up your system to connect. o Request and register your address space allocation. o Request and register an autonomous system number, if needed. o Register with a routing database, if needed. o Register your country's domain name, if needed. o Request and register your IN-ADDR.ARPA domain name, if needed. Prerequisites This document assumes that you have examined different alternatives for physical connectivity and will assist you in navigating the Internet infrastructure so that you can use that connectivity. In choosing your upstream provider, you should consider their ability to deal with the Internet infrastructure. What will you be doing and what role will you play? o If you are interested in connecting yourself (or a small organization), you are an Internet end user. You will probably want to contact an Internet Service Provider (ISP) for most of your needs. Read section I and the first part of section II. o If you are interested in connecting your organization and in having address space to distribute within your network, you are an Internet high volume end user. You will need more address space, but still may chose to work with an Internet Service Provider (ISP) for most of your needs. Read sections I and II. o If you are interested in connecting your organization, and in distributing addresses to your clients (who are end users), you are an Internet Service Provider (ISP). You will need to contact a Local Internet Registry (if one is available, or your upstream provider). Read section I and continue reading the rest of this document.
o If you are interested in distributing addresses to your clients and your clients are in turn distributing addresses, you are a Local Internet Registry or large ISP. You will probably need to contact the Regional Internet Registry in your geographical area. Read section I and continue reading the rest of this document.
prefixes in the form + country code (e.g., +011), city code, and local telephone number). The administrative contact should be a member of your organization and must reside in the country. The technical contact should be the key network support person and may be represented initially by someone outside of the country. Note that the technical contact must transition to a network support person residing in the country. The Internet Registries will request this information in the form of database entries called objects. For example, on the RIPE template, the administrative contact should be listed in the admin-c field in the database objects, and the technical contact in the tech-c field in the database objects (more information on database objects follows in section II D below). 2. Determine your cost-recovery charging scheme, if needed, so that you can sustain operations. No form or record will specifically request this, but it is important that you project your costs adequately so that you can assess fees to cover them and ensure stability of operations. 3. Diagram your network topology. Determine the number of groups and end users. Describe the size and shape of your current network. Design your addressing plan based on this information. It may be helpful to consider your organization chart when doing this, if you anticipate it to be fairly stable. If you are restricted to using the local telecommunications company's telephone circuit, choose your circuit carrier based on capacity and where it lands geographically. Consider an asymmetric circuit, e.g., 128kbps in and 64kbps out, if you expect to have more incoming traffic than outgoing (e.g., if most of the traffic is expected to originate from web servers outside your network). 4. Determine to whom you will connect. See the prerequisites section for types of connection providers that might be appropriate for your situation. Determine which ISP or telecommunications company best fits your connectivity needs. 5. Predict your address space and bandwidth requirements from end user needs. Since address space is finite and must be conserved, end users are not permitted to reserve address space. Address space is based on what your needs are and how you justify those needs. Evaluation of IP address space requests is usually based on the documentation you provide for the following 24 months (as per RFC 2050), as specified
in the address space usage template and in the addressing plan you submit. Once you have used your assigned address space, you can request additional space based on an updated estimate of growth in your network. This usually includes detailed documentation, updating the appropriate regional registry database with details of your end user assignments, and assigning address space both conservatively and efficiently. You will need to justify your needs for address space by communicating your network design and should be prepared to clearly present your plan for effective use of the request. Determine your current and future user needs. If you are offering virtual web services, it is no longer necessary to assign one IP address per domain. HTTP/1.1 defines the "host" header to allow vanity names without the use of an IP address. Allocations for points of presence (POP) throughout your region should also be determined. Predictions of user behavior can be based on analysis of published rates, interviews with individual and institutional subscribers, and case histories of other countries (see "History of the Internet in Thailand"). For example, Area1 10 dialup modems 10 leased lines to organization's LANs (size of the LANs) Area2 5 dialup modems Main POP 5 servers: mail, WWW, DNS, FTP, etc. When you design your plan, you should design it for what you need now, what you believe you will need six months from now, and then one year and two years from now. 6. Set up, connect, and test your hardware and software. It is important to ensure that you have enough representative systems set up and their connectivity tested using temporary addresses before contacting the appropriate agency for address space. Appendix B for details on obtaining the documents referred to in this guide. RFC 2151, "A Primer on Internet and TCP/IP Tools and Utilities".
Appendix A. You should contact your Regional Internet Registry if 1) the ISP you are connecting to is unable or unwilling to provide address space, or 2) your particular connectivity requirements will result in non-local data to your customers possibly taking a different route over the Internet than data destined for your upstream provider's customers,
or 3) you anticipate a quick growth rate that may require changing your current upstream provider to a larger one and you wish to avoid the renumbering that such a move would require. section I.C, number 3 (above). Note that address space is allocated based on CIDR bit boundaries (see next section). The registries will need to understand your network engineering and deployment plans in significant detail before they can allocate address space. Therefore, the more detailed information you can provide, the more likely your request will be processed quickly. If you obtain address space from your ISP, it is very likely that you will need to renumber should you decide to change upstream providers and/or if you grow considerably. As this renumbering may affect your customers (and their customers, etc.) if they are using dedicated lines, you should carefully weigh the cost/benefit involved in obtaining address space from your upstream provider. If you are singly homed, you should obtain your address space from your upstream ISP. If you plan on enlarging but remaining singly homed, you should continue to obtain space this way as it promotes aggregation. If, however, you plan to be multi-homed as part of your growth plan, it would make sense to become a member of an appropriate Regional IR (or, if one exists in your region, a national Network Information Center (NIC) and obtain a /19 or "provider aggregatable" address space. The minimum routable block is often a /19, so if you plan on enlarging, it is better to pay the fees to the Regional IR now and obtain a /19 block so that you will not have to renumber later. Note that if you are an ISP in the ARIN region, ARIN has special requirements before you can do this in terms of the amount of address space you have previously used, which must be a /21. The current policy is that you must have used a /19 previously from your upstream ISP before going to ARIN, or you must be multi-homed and show you have used a /21 and be willing to renumber and ARIN will issue a /20 from a reserved /19.
As of February 8, 1999, ARIN lowered the minimum allocation size for IP addresses from a /19 to a /20. ARIN will issue initial allocations of prefixes no longer than /20. If allocations smaller than /20 are needed, ISPs and end users should request address space from their upstream provider. ARIN does not guarantee that addresses will be globally routable. APNIC and RIPE NCC do not have these requirements. For APNIC, new allocations to members will be a /19. Remember that your upstream provider should route you if you ask them. You are a customer of the ISP, so if the service is not what you need you should change ISPs. IF YOU ARE CONNECTED TO ONLY ONE PROVIDER, AND ARE NOT VERY LARGE YET, GET AN ADDRESS RANGE FROM YOUR PROVIDER. SKIP THE REST OF THIS SECTION AND ALL OF SECTION V.
Addrs Number of addresses available; note that the number of addressable hosts normally is 2 less than this number because the host parts with all equal bits (all 0s, all 1s) are reserved. Bits Size of the allocation/assignment in bits of address space. Pref Length of the prefix covering this address space. This is sometimes used to indicate the size of an allocation/assignment. Class Size of the address space in terms of class C network numbers. Mask The network mask defining the routing prefix in dotted quad notation. (From http://www.ibm.net.il/~hank/cidr.html)
rev-srv: ns.someserver.net rev-srv: ns.otherserver.net status: assigned pa (provider aggregatable) or assigned pi (provider independent) changed: firstname.lastname@example.org 960731 source: RIPE For Countries in the APNIC Region In order to obtain services from APNIC, you will need to become a member. APNIC-070 is the APNIC Membership Application. It is located at: ftp://ftp.apnic.net/apnic/docs/membership-application Send the completed form via email to APNIC at: email@example.com APNIC Address Allocation Requests: Once you have become a member, you can request IP address space using one of the three IP address request forms. If you are an organization that will use address space internally only (e.g., large enterprises such as universities, government ministries, large corporations, etc.), choose #1 (End User Address Request). If you are an organization that plans to sub-delegate address space to customers (e.g., you are an ISP), choose #2 (ISP Address Request). If you are a confederation of ISPs (e.g., national NICs, etc.), choose #3 (Confederation Address Request). 1. APNIC-074 is the APNIC End User Internet Address Request Form. 2. APNIC-065 is the APNIC Internet Services Provider Internet Address Request Form. 3. Confederations are a means by which service providers can group together to provide resource allocation and registration services tailored to their specific local language and cultural requirements. For details on how to become an APNIC recognized confederation, please see APNIC Confederation Concepts and Requirements located at: ftp://ftp.apnic.net/apnic/docs/confed-requirements APNIC-074 is the APNIC Confederation Internet Address Request Form.
Copies of all forms can be found in the following directory: ftp://ftp.apnic.net/apnic/docs or http://www.apnic.net/reg.html All completed forms should be sent to: firstname.lastname@example.org If there are strong reasons why you cannot obtain address space from your upstream ISP, and you require address space as a one-time allocation only, you can obtain address space as a "non member". For more details, see APNIC-071: http://ftp.apnic.net/apnic/docs/non-member-application and send the completed form to: email@example.com For Countries in the ARIN Region Membership in ARIN is optional and not a requirement for requesting IP address space from the registry or from your Internet service provider. If you are a large end user organization, choose #1. If you are an ISP, choose #2. 1. The form for network number assignments is located at: ftp://rs.arin.net/templates/networktemplate.txt or http://www.arin.net/templates/networktemplate.txt 2. The form for ISPs to obtain a CIDR block of IP network numbers is located at: ftp://rs.arin.net/templates/isptemplate.txt or http://www.arin.net/templates/isptemplate.txt Send either completed form via email to ARIN at: firstname.lastname@example.org with "IP request" (if you chose #1) or "ISP CIDR request" (if you chose #2) in the subject field, as appropriate.
For Countries in the RIPE Region RIPE NCC provides IP address space allocation only to contributing local Internet registries. For a description of the European Internet Registry policies and procedures, see RIPE-159, "European Internet Registry Policies and Procedures". It is located at: ftp://ftp.ripe.net/ripe/docs/ripe-159.txt RIPE-160 is Guidelines for Setting up a Local Internet Registry. It is located at: ftp://ftp.ripe.net/docs/ripe-160.txt If you have questions regarding setting up a new local IR, please contact the RIPE NCC at: email@example.com Once your local IR is established, you will get detailed information on how to submit requests to the RIPE NCC hostmaster. Send the completed form via email to RIPE NCC at: firstname.lastname@example.org If you have general queries, please contact RIPE NCC at: email@example.com RFC 1518, "An Architecture for IP Address Allocation with CIDR" and RFC 2050, "Internet Registry IP Allocation Guidelines".
the service provider's ASN. If there is constant traffic between you and a point in another country, you may want to connect to a second ISP in that country. Note that the resultant multi-homing generally makes the system more robust and may also change registry (and therefore request) relationships. It also increases costs greatly. You may have to reduce traffic on your international lines by choosing to connect to a local exchange point. This allows traffic to stay within your country and off of expensive international links. If you implement this plan, you will be multi-homed and will need to read the autonomous systems and routing sections of this document. http://ftp.apnic.net/apnic/docs/asn-request Send the completed form via email to APNIC at: firstname.lastname@example.org For Countries in the ARIN Region A complete listing of assigned ASNs is located at: ftp://rs.arin.net/netinfo/asn.txt The ASN registration form is located at: ftp://rs.arin.net/templates/asntemplate.txt or http://www.arin.net/templates/asntemplate.txt Send the completed form via email to ARIN at: email@example.com with "ASN request" in the subject field.
For Countries in the RIPE Region The European Autonomous System Number Application Form and Supporting Notes form (RIPE-147) is located at: ftp://ftp.ripe.net/ripe/docs/ripe-147.txt Local IRs can send the completed form via email to RIPE at: firstname.lastname@example.org RFC 1930, "Autonomous Systems (AS)".
Example Americas Exchange Points: MAE-EAST Metropolitan Area Ethernet - East MAE-WEST Metropolitan Area Ethernet - West PAIX Palo Alto Internet Exchange Depending on the requirements of your international ISP, you may be able to have only a default route to them and specific routes to other suppliers if you have an in-country exchange point. Or they may require that you carry a full set of routes, treating your connection to the in-country exchange point as if it were a multi- homed connection. http://www.radb.net/ As of January 1, 2000, the transition to the Routing Policy Specification Language (RSPL) is complete. RIPE-181 object submissions are no longer accepted. For more information, see:
http://www.merit.edu/radb/announce.html With the exception of the Routing Arbiter Database, each registry serves a limited customer base. ANS, Cable and Wireless, and Bell Canada accept routing registrations for their customers alone, and the RIPE NCC oversees European registrations. The Routing Arbiter Database is unique in that it handles registrations for networking organizations not covered by the other routing registries. The Routing Arbiter also provides coordination among all the registries to ensure consistent representation of routing policies. All Regional IRs need to register with one (only one) of the routing databases in the IRR. If you are announcing routes via BGP4, you need to register your routes in the Routing Registry in only one of the IRR's. Logically, this will be the "closest" IRR to you. However, note that some ISPs do not use the regional registries or RADB.
RFC 1812, "Requirements for IP Version 4 Routers". See also RFC 1786, "Representation of IP Routing Policies in a Routing Registry (ripe-181++)". For more information on CIDR and routing, see RFC 1817, "CIDR and Classful Routing". Appendix A). See ISO 3166 for more information and a current listing of country codes (Appendix C). A hierarchy of names may, and normally should be, created under each TLD. There is a wide variation in the structure of country domains. In some countries there is a substantial hierarchy, while in others the structure is flat. In some country domains the second levels are generic categories, while in others they are based on geography, and in still others, organization names are listed directly under the country code. Examples of second level generic categories are ac or edu (academic or education), co or com (corporate or commercial), and go or gov (government). RFC 1912 for information on common errors in preparing name servers).
The whois master database is the authoritative source of information on .com, .net, .org, and .edu domain name registrations. It is currently maintained by Network Solutions, Inc. and holds referral pointers to which whois database contains the record for the domain name. To apply to manage a country code top-level domain you should: 1. First, if you are on a UNIX host, use the "whois" command to see if the domain is already registered: whois =<domain> 2. If the domain does not already have an administrative contact, request a Domain Name Agreement template from IANA by sending email to: email@example.com RFC 1591 for domain name dispute information. Note that you will need to resolve the dispute within your country before you contact IANA. RFC 1591, "Domain Name System Structure and Delegation"; RFC 1713, "Tools for DNS Debugging"; and RFC 1912, "Common DNS Operational and Configuration Errors".
ftp://ftp.apnic.net/apnic/docs/in-addr-request CAUTION: You must set-up your name server to accept the delegation prior to submission of this form. Send the completed form via email to APNIC at: firstname.lastname@example.org For Countries in the ARIN Region How IN-ADDR.ARPA is registered is dependent on the registration of the block needing reverse entries. For example, all blocks that have been registered directly from the Regional IR may have IN-ADDR.ARPA delegation established by ARIN. In this case, IN-ADDR.ARPA delegations are registered using the ARIN modify template. This template can be found at: ftp://ftp.arin.net/templates/modifytemplate.txt or http://www.arin.net/templates/modifytemplate.txt Instructions for completing the template can be found at the bottom of the template. CAUTION: Do not list your network number in reverse on the template.
Send the completed form via email to ARIN at: email@example.com All blocks that have been reassigned to your organization by an ISP will have IN-ADDR.ARPA established by your provider. In this case, contact the ISP that reassigned IP address space to your organization and coordinate IN-ADDR.ARPA delegation. For Countries in the RIPE Region The domain object needs to be entered in the RIPE database before requesting reverse delegation. domain: 0.194.in-addr.arpa descr: Our organization allocation admin-c: NIC-handle of administrative contact (e.g., JLC-2RIPE) tech-c: NIC-handle of technical contact zone-c: NIC-handle of zone contact nserver: Name server (e.g., ns.someserver.net) nserver: ns.otherserver.net nserver: ns.ripe.net changed: firstname.lastname@example.org 960731 source: RIPE NOTE: One of the name servers has to be ns.ripe.net The domain object described above should be included in the request, as well as zone file entries for the zone above the one requested. For example, if a reverse delegation is requested for 1.193.in- addr.arpa, the relevant zone file entries should be included for 193.in-addr.arpa; whereas if a reverse delegation is requested for 2.2.193.in-addr.arpa, the zone file entries should be included for 2.193.in-addr.arpa. Send the completed object(s) via email to RIPE at: email@example.com
http://www.caida.org/ Send email with questions or comments to: firstname.lastname@example.org section VII.  Malkin, G., "Internet Users' Glossary", FYI 18, RFC 1983, August 1996.  Hinden, R., Editor, "Applicability Statement for the Implementation of Classless Inter-Domain Routing (CIDR)", RFC 1517, September 1993.
 Rekhter, Y. and T. Li, "An Architecture for IP Address Allocation with CIDR", RFC 1518, September 1993.  Fuller, V., Li, T., Yu, J. and K. Varadhan, "Classless Inter- Domain Routing (CIDR): an Address Assignment and Aggregation Strategy", RFC 1519, September 1993.  Rekhter, Y. and C. Topolcic, "Exchanging Routing Information Across Provider Boundaries in the CIDR Environment", RFC 1520, September 1993.  Postel, J., "Domain Name System Structure and Delegation", RFC 1591, March 1994.  Wijnen, B., Carpenter, G., Curran, K., Sehgal, A. and G. Waters, "Simple Network Management Protocol Distributed Protocol Interface Version 2.0", RFC 1592, March 1994.  Ramao, A., "Tools for DNS debugging", RFC 1713, November 1994.  Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, June 1995.  Rekhter, Y., "CIDR and Classful Routing", RFC 1817, August 1995.  Barr, D., "Common DNS Operational and Configuration Errors", RFC 1912, February 1996.  Hawkinson, J. and T. Bates, "Guidelines for Creation, Selection, and Registration of an Autonomous System", RFC 1930, March 1996.  Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.  Hubbard, K., Kosters, M., Conrad, D., Karrenberg, D. and J. Postel, "Internet Registry IP Allocation Guidelines", BCP 12, RFC 2050, November 1996.  Kessler, G. and S. Shepard, "A Primer On Internet and TCP/IP Tools and Utilities", FYI 30, RFC 2151, June 1997.  ISO 3166: "Codes for the Representation of Names of Countries"  Palasri, S., Huter, S., and Wenzel, Z. "The History of the Internet in Thailand", University of Oregon Books, 1999.
http://www.iana.org/ o Internet Corporation for Assigned Names and Numbers (ICANN) From the ICANN web site: The Internet Corporation for Assigned Names and Numbers (ICANN) is a technical coordination body for the Internet. Created in October 1998 by a broad coalition of the Internet's business, technical, academic, and user communities, ICANN is assuming responsibility for a set of technical functions previously performed under U.S. Government contract by IANA and other groups. Specifically, ICANN coordinates the assignment of the following identifiers that must be globally unique for the Internet to function: Internet domain names, IP address numbers, protocol parameter and port numbers. In addition, ICANN coordinates the stable operation of the Internet's root server system. As a non-profit, private-sector corporation, ICANN is dedicated to preserving the operational stability of the Internet; to promoting competition; to achieving broad representation of global Internet communities; and to developing policy through private-sector, bottom-up, consensus-based means. ICANN welcomes the participation of any interested Internet user, business, or organization.
Email: email@example.com Postal: Internet Corporation for Assigned Names and Numbers (ICANN) 4676 Admiralty Way, Suite 330 Marina del Rey, CA 90292 USA Telehone: +1-310-823-9358 Fax: +1-310-823-8649 Internet: http://www.icann.org/ o InterNIC The InterNIC was a cooperative activity between the National Science Foundation, General Atomics, AT&T, and Network Solutions, Inc. The joint activity InterNIC no longer exists. Currently, Network Solutions runs the central registry according to the shared registry model specified by ICANN for registration of second-level domain names under the generic top-level domains .com, .net, and .org. For information on accredited registrars for .com, .net, and .org, please see: http://www.icann.org/registrars/accredited-list.html (note that Network Solutions is an accredited registrar as well as the entity running the registry). Email: firstname.lastname@example.org Postal: Network Solutions, Inc. 505 Huntmar Park Dr. Herndon, VA 20170 US Telephone: +1-703-742-4777 Fax: +1-703-742-9552 Internet: http://www.networksolutions.com/ Regional Internet Registries (IRs) Regional IRs operate in large geopolitical regions such as continents. Currently, there are three Regional IRs: ARIN for the Americas, the Caribbean, and Africa; RIPE NCC for Europe, Africa, and the Middle East; and APNIC for the Asia Pacific region. The specific duties of the Regional IRs include coordination and representation of all local Internet Registries in their respective region.
o APNIC Asia Pacific Network Information Center (APNIC) is a non-profit Internet registry for the Asia Pacific region. APNIC provides IP address allocation, Autonomous System Number (ASN) assignment, and IN-ADDR.ARPA registration. Email: email@example.com Postal: APNIC Box 2131 Milton Queensland 4064 Australia Telephone: +61-7-3367-0490 Fax: +61-7-3367-0482 Internet: http://www.apnic.net/ o ARIN The American Registry for Internet Numbers (ARIN) is a non-profit Internet registry that was established for the purpose of administration and registration of Internet Protocol (IP) numbers to the geographical areas that were previously managed by Network Solutions, Inc. These areas include, but are not limited to, North America, South America, Africa, and the Caribbean region. ARIN provides IP address allocation, Autonomous System Number (ASN) assignment, and IN-ADDR.ARPA registration. Email: firstname.lastname@example.org Postal: 4506 Daly Drive Suite 200 Chantilly, VA 20151 Telephone: +1-703-227-0660 Fax +1-703-227-0676 Internet: http://www.arin.net/ o RIPE NCC Reseaux IP Europens Network Coordination Centre (RIPE NCC) is a non- profit Internet registry for the European, North African, and Middle East regions. RIPE NCC provides IP address allocation, Autonomous System Number (ASN) assignment, and IN-ADDR.ARPA registration. Email: email@example.com Postal: Singel 258 1016 AB Amsterdam The Netherlands Phone: +31-20-535-4444 Fax: +31-20-535-4445 Internet: http://www.ripe.net/
2. Via electronic mail, ftp, or the World Wide Web. Send email to the appropriate address shown below with the message body as specified. APNIC Documentation For APNIC documents and templates, "ftp" to ftp.apnic.net and "cd" to /apnic/docs. APNIC no longer has an electronic mail method of form retrieval. Many of APNIC's request forms are also available on the web site at: http://www.apnic.net/reg.html ARIN Documentation For ARIN templates, "ftp" to rs.arin.net and "cd" to /templates. You can also obtain templates via the web site at: http://www.arin.net/templates.html Other ARIN documentation is available at: http://www.arin.net/docs.html Or send email to: firstname.lastname@example.org RIPE Documentation For RIPE documents and forms, "ftp" to ftp.ripe.net/ripe and "cd" to /docs or cd to /forms. Or send email to: email@example.com with send help in the body of the message. http://www.iso.ch/infoe/agency/3166-1.htm
Full Copyright Statement Copyright (C) The Internet Society (2000). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.