rfc2901.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

   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]

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:

      [e-mail]

   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]

RFC 2901      Administrative Internet Infrastructure Guide   August 2000


   Send the completed form via email to ARIN at:

      [e-mail]

   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: [e-mail] 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:

      [e-mail]

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]

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:

     [e-mail]

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]

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]

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: [e-mail]


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

   EMail: [e-mail]


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

   EMail: [e-mail]


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

   EMail: [e-mail]















Wenzel, et al.               Informational                     [Page 24]

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:          [e-mail]
   Postal:         4676 Admiralty Way, Suite 330
                   Marina del Rey, CA 90292
                   USA
   Telehone:       [phone]
   Fax:            [phone]
   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