path: root/doc/rfc/rfc2901.txt

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.

Abstract

   This 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.

Table of Contents

   Who Should Read This Document ...................................  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





Wenzel, et al.               Informational                      [Page 1]
^L
RFC 2901      Administrative Internet Infrastructure Guide   August 2000


   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.







Wenzel, et al.               Informational                      [Page 2]
^L
RFC 2901      Administrative Internet Infrastructure Guide   August 2000


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.







Wenzel, et al.               Informational                      [Page 3]
^L
RFC 2901      Administrative Internet Infrastructure Guide   August 2000


   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.

I.      Preparation of Systems and Network Planning

   STEP ONE: PREPARE INFORMATION, ORGANIZE HARDWARE, FIGURE OUT TO WHOM
   YOU WILL CONNECT, AND TEST IN-COUNTRY SYSTEMS.

A.  What do I need to connect to the Internet?

   You can connect using dial-up or dedicated lines, and you can choose
   UUCP or IP.  It is preferable to be running the UNIX operating system
   with TCP/IP over a dedicated line, although you can begin by using
   UUCP over a dial-up line.  Although there are alternatives to UNIX,
   for historical reasons and robustness UNIX is better prepared to
   handle Internet connectivity.  It is best to use TCP/IP inside your
   network even if you use another method for your external
   connectivity.

   You will need to obtain an Internet Protocol (IP) address, or block
   of addresses, and a domain name.  You may also need an Autonomous
   System Number (ASN) and an IN-ADDR.ARPA (reverse addressing) domain
   name.  However, you may begin by having dial-up connectivity to
   another organization that supports one or more mail exchange (MX)
   record(s) for your site.  This would allow you to receive email at
   your own domain name without requiring you to invest as much
   initially.

B.  What connectivity medium should I choose?

   You may be constrained by telecommunications regulations in your
   country as to your choice of dial-up, digital phone lines, fiber
   optic cable, or satellite suppliers.  If not, cost, bandwidth, and
   reliability will determine your choice.

C.  What else do I need to do?

   Before you do anything else:

   1. Designate an administrative contact person and a technical contact
   person.

   Choose one person to be the administrative contact and another person
   to be the technical contact.  Write down their full names, email and
   postal addresses, and telephone and fax numbers (with country



Wenzel, et al.               Informational                      [Page 4]
^L
RFC 2901      Administrative Internet Infrastructure Guide   August 2000


   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



Wenzel, et al.               Informational                      [Page 5]
^L
RFC 2901      Administrative Internet Infrastructure Guide   August 2000


   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.

D.  How do I get the documents referred to in this guide?

   See Appendix B for details on obtaining the documents referred to in
   this guide.

E.  Section References

   For more information on TCP/IP, see RFC 2151, "A Primer on Internet
   and TCP/IP Tools and Utilities".



Wenzel, et al.               Informational                      [Page 6]
^L
RFC 2901      Administrative Internet Infrastructure Guide   August 2000


II.     Address Space Allocation

   STEP TWO: OBTAIN ADDRESS SPACE ALLOCATION AND REGISTRATION FROM THE
   ISP YOU ARE CONNECTING TO, OR (AS A LAST RESORT) YOUR REGIONAL
   REGISTRY.

   Internet Protocol (IP) addresses (under the current version 4) are
   32-bit numbers usually expressed as 4 octets in dotted decimal
   notation (for example, 128.223.162.27, which is the IP address for
   the Network Startup Resource Center (NSRC) web server at the time of
   this writing).  Public IP addresses make up the Internet address
   space.  Addresses are allocated in a hierarchical manner and are
   designed to be unique.

   The Internet Assigned Numbers Authority (IANA) allocates large
   address blocks to the three current Regional Internet Registries
   (IRs): ARIN, APNIC, and RIPE NCC which, in turn, allocate smaller
   blocks to Local Internet Registries or large ISPs.  Local Internet
   Registries, which are typically ISPs or collections of ISPs
   represented at a country level, and large ISPs process the vast
   majority of address space assignments to ISPs and end users

   Contact the Internet service provider from whom you are getting your
   connectivity services (your upstream provider) with an address
   allocation request.  It is important and required that you contact
   your upstream provider first, and not the Regional IR automatically.
   The first question the Regional Registry will ask you is why you
   cannot get address space from your upstream provider.

A.  Who is my upstream provider?

   If there is an ISP already functioning in your country, contact them
   directly.  If you are to be the first connection in your country, you
   may need to contact your Regional IR in your geographic region, but
   you should always contact your upstream provider first for assistance
   and guidance.  Since address allocation is hierarchical, the
   administrative organizations and procedures also represent this
   hierarchical structure.  It is important not to skip a step in the
   hierarchy.  Current Regional Registries include ARIN (the Americas,
   Caribbean, and Africa), RIPE (Europe, Africa, and the Middle East),
   and APNIC (the Pacific Rim and Asia).  Contact information for these
   organizations is listed in 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,



Wenzel, et al.               Informational                      [Page 7]
^L
RFC 2901      Administrative Internet Infrastructure Guide   August 2000


   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.

B.  How much address space should I ask for?

   Regional IRs typically assign address blocks on the basis of an
   immediate need and projected utilization rate within one year.  (If
   you are in the ARIN region, it is one year for end user organizations
   and three months for ISPs.)  Calculate your address space request
   accordingly.  It is recommended to include the organization chart and
   network topology diagram referred to in 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.






Wenzel, et al.               Informational                      [Page 8]
^L
RFC 2901      Administrative Internet Infrastructure Guide   August 2000


   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.

C.  What is CIDR?

   CIDR stands for Classless Inter-Domain Routing.  Historically, IP
   addresses were assigned within classes: Class A (8 bits of network
   address, 24 bits of host address), Class B (16 bits of network
   address, 16 bits of host address), or Class C (24 bits of network
   address, 8 bits of host address).  With the advent of CIDR, address
   space is now allocated and assigned on bit boundaries.  Using CIDR
   means you are able to assign addresses corresponding with the number
   of hosts on the network, thereby conserving address space.

   The following table illustrates this:

   Addrs Bits  Pref  Class         Mask

   1       0       /32                     255.255.255.255
   2       1       /31                     255.255.255.254
   4       2       /30                     255.255.255.252
   8       3       /29                     255.255.255.248
   16      4       /28                     255.255.255.240
   32      5       /27                     255.255.255.224
   64      6       /26                     255.255.255.192
   128     7       /25                     255.255.255.128
   256     8       /24     1C              255.255.255.0
   512     9       /23     2C              255.255.254.0
   1K      10      /22     4C              255.255.252.0
   2K      11      /21     8C              255.255.248.0
   4K      12      /20     16C             255.255.240.0
   8K      13      /19     32C             255.255.224.0




Wenzel, et al.               Informational                      [Page 9]
^L
RFC 2901      Administrative Internet Infrastructure Guide   August 2000


   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)

D.  How do I request and register address space?

   You will need to send a database object to the appropriate registry
   to request and register address space.  The registration databases
   are composed of records that are a series of fields separated by one
   or more blank lines; each field consists of two parts, the tag and
   the value.  Do not modify the tags in the templates or errors will
   occur.  Values for particular fields are specified in the templates;
   be careful to enter appropriate information.

   The first line of a template denotes the record type.  For example,
   an IP address template's first line is inetnum, therefore the record
   is known as an inetnum object.  This first line is also used as the
   primary key for the record, therefore if you want to modify the first
   field of the record, the only way to do so is to delete the record
   entirely and add a new record with the corrected information.

   For illustration, here is the RIPE inetnum object.

      inetnum: [IP address range that will be assigned]
      netname: Network-Name
      descr: Network-Name Communications Company, Town
      admin-c: NIC-handle of administrative contact
      tech-c: NIC-handle of technical contact
      country: ISO 3166-country-code



Wenzel, et al.               Informational                     [Page 10]
^L
RFC 2901      Administrative Internet Infrastructure Guide   August 2000


      rev-srv: ns.someserver.net
      rev-srv: ns.otherserver.net
      status: assigned pa (provider aggregatable)
        or assigned pi (provider independent)
      changed: email@address.net 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:

      member-apply@apnic.net

   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.






Wenzel, et al.               Informational                     [Page 11]
^L
RFC 2901      Administrative Internet Infrastructure Guide   August 2000


   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:

      hostmaster@apnic.net

   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:

      billing@apnic.net

   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:

      hostmaster@arin.net

   with "IP request" (if you chose #1) or "ISP CIDR request" (if you
   chose #2) in the subject field, as appropriate.




Wenzel, et al.               Informational                     [Page 12]
^L
RFC 2901      Administrative Internet Infrastructure Guide   August 2000


   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:

      new-lir@ripe.net

   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:

      ncc@ripe.net

   If you have general queries, please contact RIPE NCC at:

      ncc@ripe.net

E.  Section References

   For more information on IP addresses, see RFC 1518, "An Architecture
   for IP Address Allocation with CIDR" and RFC 2050, "Internet Registry
   IP Allocation Guidelines".

III.    Autonomous Systems (AS)

   STEP THREE:  IF NEEDED, OBTAIN AN AUTONOMOUS SYSTEM NUMBER.

A.  What is an ASN and do I need one?

   Autonomous System Numbers (ASNs) are used to facilitate routing in
   multi-homed environments.  They are allocated when your routing
   policy is different from your provider's.  This generally means your
   site is multi-homed.  In nearly all cases, unless you are multi-homed
   to more than one ISP, you will not need an ASN.  If your routing
   policy does not differ from your service provider's, you should use



Wenzel, et al.               Informational                     [Page 13]
^L
RFC 2901      Administrative Internet Infrastructure Guide   August 2000


   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.

B.  How do I register an ASN?

   Since the ASN space is quite limited, request only what you really
   need when you need it.

   For Countries in the APNIC Region

   APNIC-066 is the ASN Request Form. The form is located at:

      http://ftp.apnic.net/apnic/docs/asn-request

   Send the completed form via email to APNIC at:

      hostmaster@apnic.net

   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:

      hostmaster@arin.net

   with "ASN request" in the subject field.







Wenzel, et al.               Informational                     [Page 14]
^L
RFC 2901      Administrative Internet Infrastructure Guide   August 2000


   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:

   hostmaster@ripe.net

C.  Section References

   For more information on ASNs, see RFC 1930, "Autonomous Systems
   (AS)".

IV.     Routing and Exchange Points

   STEP FOUR: IF NEEDED, REGISTER WITH A ROUTING DATABASE.

A.  Do I need to register with a routing database?

   You do not need to register with a routing database if you are simply
   carrying default routes to your (single) ISP.  If you get your
   address space from an ISP, the ISP will register you.  If you are
   connected to more than one ISP, then you should register with a
   routing database.

   The more multi-homed you are, the larger your routing tables need to
   be.  If you are connected to public exchange points (see examples
   below), or to more than one backbone ISP, you need to carry full
   routing tables and run without a default route.

   Example European Exchange Points:

   LINX            London Internet Exchange
   M9-IX           Moscow Internet Exchange
   NIX.CZ          Neutral Internet Exchange, Czech Republic

   Example Asia/Pacific Exchange Points:

   AUIX            Australia Internet Exchange
   HKIX            Hong Kong Internet Exchange
   JPIX            Japan Internet Exchange







Wenzel, et al.               Informational                     [Page 15]
^L
RFC 2901      Administrative Internet Infrastructure Guide   August 2000


   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.

B.  What about CIDR and routing?

   All registries use CIDR. All major router vendors (Cisco, 3Com,
   Nortel, Proteon, IBM, etc.) support CIDR.  CIDR Internet routers use
   only the prefix of the destination address to route traffic to a
   subnetted environment.

C.  How do I choose a routing database?

   The Internet Routing Registry (IRR) describes registries maintained
   by several national and international networking organizations.
   These currently include the RIPE Network Coordination Centre (NCC),
   ANS (Advanced Network Solutions, Inc.), Bell Canada (formerly
   CA*net), Cable and Wireless (CW), and the Routing Arbiter Database
   (RADB).  The IRR is a way for ASNs to publicize their own intended
   routing policies without having to request a change from a go-
   between.

   "whois" queries to "whois.ra.net" return data that they gather from
   the entire IRR set of routing registries.  Tools such as "peval" and
   "rtconfig" return data only from the RADB.  Thus, when running those
   tools and desiring data from a set of registries, one must enumerate
   them as in the following example.  "whois" queries to the client
   configure the precedence of routing databases.  For example:

      @RtConfig set sources = "TEST, RADB, RIPE, ANS, BELL, CW"

   There are several other registries, such as ALTDB.  A list, and other
   information on RADB, is available at:

      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:



Wenzel, et al.               Informational                     [Page 16]
^L
RFC 2901      Administrative Internet Infrastructure Guide   August 2000


      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.

D.  How do I register in the RADB (The Americas)?

   You need to submit three types of database records to the RADB: one
   or more maintainer objects, an AS object, and one or more route
   objects.

   To specify the individuals who are allowed to update your records in
   the RADB, fill out one or more maintainer objects and send them via
   email to:

      db-admin@radb.net

   You need to submit a maintainer object before you can register any AS
   or route objects.

   To describe the autonomous system that announces your routes, fill
   out an AS object and submit it via email to:

      auto-dbm@radb.net

   AS objects are also called aut-num objects.

   To register your routes, fill out one or more route objects, and send
   them to RADB via email to:

      auto-dbm@radb.net

   Note that most of the IRR participants have the auto-dbm@xx.net email
   address function for accepting updates to the IRR automatically.





Wenzel, et al.               Informational                     [Page 17]
^L
RFC 2901      Administrative Internet Infrastructure Guide   August 2000


E.  Section References

   For more information on routers, see 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".

V.      Domain Name Registration

   STEP FIVE:  REGISTER YOUR DOMAIN NAME.

A.  What is a country domain?

   The Domain Name System (DNS) specifies the naming of computers within
   a hierarchy.  Top-Level Domain (TLD) names include generic TLDs
   (gTLDs) and two-letter country codes (ccTLDs).  Examples of gTLDs
   include .com (commercial), .net (network), and .org (organization).
   Examples of two-letter country codes are .ca for Canada, .fr for
   France, and .id for Indonesia.  ISO 3166 is used as a basis for
   country code top-level domain names.  Country codes are assigned by
   the International Organization for Standardization (ISO) in
   cooperation with the United Nations.  The Internet Assigned Numbers
   Authority (IANA) directly registers all country-code top-level
   domains, however it is not involved in the allocation of codes to
   countries.  IANA is a function of the Internet Corporation for
   Assigned Names and Numbers (ICANN, see 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).

B.  How do I register as a country domain?

   First check that: (1) the domain is still available, few are, (2) you
   have someone in your country as the administrative contact, and (3)
   your name servers are prepared (see RFC 1912 for information on
   common errors in preparing name servers).





Wenzel, et al.               Informational                     [Page 18]
^L
RFC 2901      Administrative Internet Infrastructure Guide   August 2000


   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:

      iana@iana.org

C.  What if my country is already registered?

   If your country is already registered, contact the country-code
   administrator to register a new second-level domain name.

   Please note that ARIN, RIPE, and APNIC do not handle domain names
   (other than IN-ADDR.ARPA).  If you want to register a domain name
   directly under a top-level domain (TLD), please contact the
   appropriate TLD administrator.

D.  How do I resolve a country domain name dispute?

   See RFC 1591 for domain name dispute information.  Note that you will
   need to resolve the dispute within your country before you contact
   IANA.

E.  Section References

   For more information on domain names, see RFC 1591, "Domain Name
   System Structure and Delegation"; RFC 1713, "Tools for DNS
   Debugging"; and RFC 1912, "Common DNS Operational and Configuration
   Errors".

VI.     IN-ADDR.ARPA Domain Delegation

   STEP SIX:  IF NEEDED, REGISTER YOUR IN-ADDR.ARPA DOMAIN.






Wenzel, et al.               Informational                     [Page 19]
^L
RFC 2901      Administrative Internet Infrastructure Guide   August 2000


A.  What is an IN-ADDR.ARPA domain and do I need one?

   An IN-ADDR.ARPA domain allows for mapping of IP addresses into domain
   names.  This is often referred to as "inverse addressing" because it
   is the opposite of the domain name to IP address resolution.  IN-ADDR
   domains are represented using the network number in reverse.  For
   example, the IN-ADDR domain for network 123.45.67.0 is represented as
   67.45.123.in-addr.arpa.

   You almost always need reverse resolution.

B.  How do I register an IN-ADDR.ARPA domain?

   You should ask your upstream provider about registering your IN-
   ADDR.ARPA domains.  If you are working directly with a regional
   registry, see below.

   For Countries in the APNIC Region

   The IN-ADDR.ARPA Delegation Form is APNIC-064 and is located at:

      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:

      domreg@rs.apnic.net

   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.




Wenzel, et al.               Informational                     [Page 20]
^L
RFC 2901      Administrative Internet Infrastructure Guide   August 2000


   Send the completed form via email to ARIN at:

      hostmaster@arin.net

   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: email@address.net 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:

      auto-inaddr@ripe.net

VII.    Security

A.  Is there a way to prevent unauthorized changes to my objects?

   Registries provide various security measures to prevent unauthorized
   changes to your database entries.  Contact your regional IR for more
   information.  Note that the contact information you provide in the
   database object registrations is not private.




Wenzel, et al.               Informational                     [Page 21]
^L
RFC 2901      Administrative Internet Infrastructure Guide   August 2000


VIII.   Network Optimization and Management

A.  How do I optimize traffic on my network?

   Contact the Cooperative Association for Internet Data Analysis
   (CAIDA).  CAIDA is a collaborative undertaking to promote greater
   cooperation in the engineering and maintenance of a robust, scalable
   global Internet infrastructure.  CAIDA provides a neutral framework
   to support these cooperative endeavors.

   The CAIDA web-site is located at:

      http://www.caida.org/

   Send email with questions or comments to:

     info@caida.org

Security Considerations

   Security is discussed in section VII.

Acknowledgements

   Thanks to Brian Candler, David Conrad, John Heasley, Kim Hubbard,
   Daniel Karrenberg, Anne Lord, Dawn Martin, Charles Musisi, Jon
   Postel, and April Marine and the IETF User Services Working Group for
   reviewing various versions of this document; and to Hank Nussbacher
   for permission to reprint his table on CIDR.

   Special thanks are also due to Dr. Steven Goldstein of the National
   Science Foundation for his contributions and suggestions, and to the
   National Science Foundation for partial funding of this work.

   This material is based upon work supported by the National Science
   Foundation under Grant No. NCR-961657. Any opinions, findings, and
   conclusions or recommendations expressed in this material are those
   of the author(s) and do not necessarily reflect the views of the
   National Science Foundation.

References

   [1]  Malkin, G., "Internet Users' Glossary", FYI 18, RFC 1983, August
        1996.

   [2]  Hinden, R., Editor, "Applicability Statement for the
        Implementation of Classless Inter-Domain Routing (CIDR)", RFC
        1517, September 1993.



Wenzel, et al.               Informational                     [Page 22]
^L
RFC 2901      Administrative Internet Infrastructure Guide   August 2000


   [3]  Rekhter, Y. and T. Li, "An Architecture for IP Address
        Allocation with CIDR", RFC 1518, September 1993.

   [4]  Fuller, V., Li, T., Yu, J. and K. Varadhan, "Classless Inter-
        Domain Routing (CIDR): an Address Assignment and Aggregation
        Strategy", RFC 1519, September 1993.

   [5]  Rekhter, Y. and C. Topolcic, "Exchanging Routing Information
        Across Provider Boundaries in the CIDR Environment", RFC 1520,
        September 1993.

   [6]  Postel, J., "Domain Name System Structure and Delegation", RFC
        1591, March 1994.

   [7]  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.

   [8]  Ramao, A., "Tools for DNS debugging", RFC 1713, November 1994.

   [9]  Baker, F., "Requirements for IP Version 4 Routers", RFC 1812,
        June 1995.

   [10] Rekhter, Y., "CIDR and Classful Routing", RFC 1817, August 1995.

   [11] Barr, D., "Common DNS Operational and Configuration Errors", RFC
        1912, February 1996.

   [12] Hawkinson, J. and T. Bates, "Guidelines for Creation, Selection,
        and Registration of an Autonomous System", RFC 1930, March 1996.

   [13] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
        Extensions (MIME) Part One: Format of Internet Message Bodies",
        RFC 2045, November 1996.

   [14] Hubbard, K., Kosters, M., Conrad, D., Karrenberg, D. and J.
        Postel, "Internet Registry IP Allocation Guidelines", BCP 12,
        RFC 2050, November 1996.

   [15] Kessler, G. and S. Shepard, "A Primer On Internet and TCP/IP
        Tools and Utilities", FYI 30, RFC 2151, June 1997.

   [16] ISO 3166:  "Codes for the Representation of Names of Countries"

   [17] Palasri, S., Huter, S., and Wenzel, Z. "The History of the
        Internet in Thailand", University of Oregon Books, 1999.





Wenzel, et al.               Informational                     [Page 23]
^L
RFC 2901      Administrative Internet Infrastructure Guide   August 2000


Authors' Addresses

   Zita Wenzel, Ph.D.
   Network Startup Resource Center (NSRC)
   1225 Kincaid Street
   1212-University of Oregon
   Eugene, OR 97403-1212 USA

   EMail: zita@nsrc.org


   John C. Klensin, Ph.D.
   Network Startup Resource Center (NSRC)
   1225 Kincaid Street
   1212-University of Oregon
   Eugene, OR 97403-1212 USA

   EMail: klensin@nsrc.org


   Randy Bush
   Network Startup Resource Center (NSRC)
   1225 Kincaid Street
   1212-University of Oregon
   Eugene, OR  97403-1212 USA

   EMail: randy@nsrc.org


   Steven Huter
   Network Startup Resource Center (NSRC)
   1225 Kincaid Street
   1212-University of Oregon
   Eugene, OR 97403-1212 USA

   EMail: sghuter@nsrc.org















Wenzel, et al.               Informational                     [Page 24]
^L
RFC 2901      Administrative Internet Infrastructure Guide   August 2000


Appendix A:     The Internet Agencies

   o  The Internet Assigned Numbers Authority (IANA)

   IANA is the central coordinator for the assignment of unique
   parameter values for Internet protocols and for all address space and
   name space used in the Internet.  IANA allocates parts of the
   Internet address space to Regional Internet Registries (IRs) for
   distribution to Local IRs and ISPs.  IANA is also responsible for the
   coordination and management of the Domain Name System (DNS).

   Note that as of 1999, IANA is a function of the Internet Corporation
   for Assigned Names and Numbers (ICANN), the non-profit corporation
   that is the top-level administration authority of the global
   Internet.

   Email:          iana@iana.org
   Postal:         4676 Admiralty Way, Suite 330
                   Marina del Rey, CA 90292
                   USA
   Telehone:       +1-310-823-9358
   Fax:            +1-310-823-8649
   Internet:       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.




Wenzel, et al.               Informational                     [Page 25]
^L
RFC 2901      Administrative Internet Infrastructure Guide   August 2000


   Email:          icann@icann.org
   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:          hostmaster@netsol.com
   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.






Wenzel, et al.               Informational                     [Page 26]
^L
RFC 2901      Administrative Internet Infrastructure Guide   August 2000


   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:          hostmaster@apnic.net
   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:          hostmaster@arin.net
   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:          ncc@ripe.net
   Postal:         Singel 258
                   1016 AB Amsterdam
                   The Netherlands
   Phone:          +31-20-535-4444
   Fax:            +31-20-535-4445
   Internet:       http://www.ripe.net/



Wenzel, et al.               Informational                     [Page 27]
^L
RFC 2901      Administrative Internet Infrastructure Guide   August 2000


Appendix B:     Documentation

   Internet Documentation

   For general Internet documentation, "ftp" to rfc-editor.org and "cd"
   to the /rfc subdirectory for Request for Comments documents.

   Details on obtaining these documents via ftp or email may be obtained
   by sending an email message to:

      rfc-info@rfc-editor.org

   with the message body  help: ways_to_get_rfcs.  For example:

      To: rfc-info@isi.edu
      Subject: getting rfcs

      help: ways_to_get_rfcs

   Documents, Templates, and Forms

   The documents, templates, and forms referenced in this guide are
   available from the document stores in the directories listed in the
   URLs (Uniform Resource Locators).  Organizations without connectivity
   wishing to obtain copies of the referenced documents should contact
   their Local IR to arrange postal delivery of one or more of the
   documents.  Note that fees may be associated with the delivery of
   hardcopy versions of documents.

   The document stores can be accessed in two ways:

   1.  Via anonymous FTP (File Transfer Protocol).

   Using your ftp program, connect to the appropriate host computer
   shown below using your email address as the password.  Use the "cd"
   (change directory) command to connect to the appropriate
   subdirectory, then use the "get" command to retrieve the specific
   file.  For example:

   ftp rs.apnic.net (for countries in the Asia/Pacific region)
   ftp rs.arin.net (for countries in the Americas)
   ftp rs.ripe.net (for countries in Europe or North Africa)

      login:  anonymous
      password:  your_email_address

      cd netinfo
      get <domain>_info.txt



Wenzel, et al.               Informational                     [Page 28]
^L
RFC 2901      Administrative Internet Infrastructure Guide   August 2000


   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:

      hostmaster@arin.net

   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:

      mail-server@ripe.net

   with send help in the body of the message.

Appendix C:     Country Codes

   The International Organization for Standardization (ISO) 3166
   Maintenance Agency and ISO 3166 current list of two-letter country
   codes is available via:

      http://www.iso.ch/infoe/agency/3166-1.htm



Wenzel, et al.               Informational                     [Page 29]
^L
RFC 2901      Administrative Internet Infrastructure Guide   August 2000


Appendix D:     Acronyms

   ANS             Advanced Network Services, Inc.
   ASN             Autonomous System Number
   APNIC           Asia Pacific Network Information Center
   ARIN            American Registry for Internet Numbers
   AS              Autonomous System
   CANET           Canada Net
   CIDR            Classless Inter-Domain Routing
   DNS             Domain Name System
   gTLD            Generic Top-Level Domain
   IANA            Internet Assigned Numbers Authority
   InterNIC        Internet Network Information Center
   IP              Internet Protocol
   IR              Internet Registry
   IRR             Internet Routing Registry
   ISO             International Organization for Standardization
   ISP             Internet Service Provider
   LINX            London Internet Exchange
   NCC             Network Coordination Centre
   NIC             Network Information Center
   NSRC            Network Startup Resource Center
   POP             Point of Presence
   RADB            Routing Arbiter Data Base
   RFC             Request for Comments
   RIPE            Reseaux IP Europeans
   TCP/IP          Transmission Control Protocol/Internet Protocol
   TLD             Top-Level Domain























Wenzel, et al.               Informational                     [Page 30]
^L
RFC 2901      Administrative Internet Infrastructure Guide   August 2000


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.



















Wenzel, et al.               Informational                     [Page 31]
^L