rfc2050.txt

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

Network Working Group                                      K. Hubbard
Request for Comments: 2050                                 M. Kosters
Obsoletes: 1466                                              InterNIC
BCP: 12                                                     D. Conrad
Category: Best Current Practice                                 APNIC
                                                        D. Karrenberg
                                                                 RIPE
                                                            J. Postel
                                                                  ISI
                                                        November 1996


               INTERNET REGISTRY IP ALLOCATION GUIDELINES

Status of this Memo

   This document specifies an Internet Best Current Practices for the
   Internet Community, and requests discussion and suggestions for
   improvements.  Distribution of this memo is unlimited.

IESG Note:

   By approving this document as a Best Current Practice,the IESG
   asserts its belief that this policy described herein is an accurate
   representation of the current practice of the IP address registries
   with respect to address assignment.  This does not constitute
   endorsement or recommendation of this policy by the IESG. The IESG
   will reevaluate its approval of this document in December 1997 taking
   into consideration the results of the discussions that will be take
   place in the IRE Working Group between now and then.

Abstract

   This document describes the registry system for the distribution of
   globally unique Internet address space and registry operations.
   Particularly this document describes the rules and guidelines
   governing the distribution of this address space.

   This document describes the IP assignment policies currently used by
   the Regional Registries to implement the guidelines developed by the
   IANA. The guidelines and these policies are subject to revision at
   the direction of the IANA. The registry working group (IRE WG) will
   be discussing these issues and may provide advice to the IANA about
   possible revisions.

   This document replaces RFC 1466, with all the guidelines and
   procedures updated and modified in the light of experience.




Hubbard, et. al.         Best Current Practice                  [Page 1]

RFC 2050       Internet Registry IP Allocation Guidelines  November 1996


   This document does not describe private Internet address space and
   multicast address space.  It also does not describe regional and
   local refinements of the global rules and guidelines.

   This document can be considered the base set of operational
   guidelines in use by all registries.  Additional guidelines may be
   imposed by a particular registry as appropriate.

Table of Contents

    1.  Introduction.......................................2
    2.  Allocation Framework...............................4
    2.1  Guidelines for Internet Service Providers.........4
    2.2  Submission of Reassignment Information............6
    3.   Assignment Framework..............................7
    3.1  Common Registry Requirements......................7
    3.2  Network Engineering Plans.........................8
    3.3  Previous Assignment History.......................9
    3.4  Network Deployment Plans..........................9
    3.5  Organization Information..........................9
    3.6  Expected Utilization Rate.........................10
    4.   Operational Guidelines for Registries.............10
    5.   In-Addr.Arpa Domain Maintenance...................11
    6.   Right to Appeal...................................11
    7.   References........................................12
    8.   Security Considerations...........................12
    9.   Authors' Addresses................................13

1. Introduction

   The addressing constraints described in this document are largely the
   result of the interaction of existing router technology, address
   assignment, and architectural history.  After extensive review and
   discussion, the authors of this document, the IETF working group that
   reviewed it and the IESG have concluded that there are no other
   currently deployable technologies available to overcome these
   limitations. In the event that routing or router technology develops
   to the point that adequate routing aggregation can be achieved by
   other means or that routers can deal with larger routing and more
   dynamic tables, it may be appropriate to review these constraints.

   Internet address space is distributed according to the following
   three goals:

   1) Conservation: Fair distribution of globally unique Internet address
   space according to the operational needs of the end-users and Internet
   Service Providers operating networks using this address space.
   Prevention of stockpiling in order to maximize the lifetime of the



Hubbard, et. al.         Best Current Practice                  [Page 2]

RFC 2050       Internet Registry IP Allocation Guidelines  November 1996


   Internet address space.

   2) Routability: Distribution of globally unique Internet addresses
   in a hierarchical manner, permitting the routing scalability of
   the addresses. This scalability is necessary to ensure proper
   operation of Internet routing, although it must be stressed that
   routability is in no way guaranteed with the allocation or
   assignment of IPv4 addresses.

   3) Registration: Provision of a public registry documenting address
   space allocation and assignment.  This is necessary to ensure
   uniqueness and to provide information for Internet trouble shooting
   at all levels.

   It is in the interest of the Internet community as a whole that the
   above goals be pursued.  However it should be noted that
   "Conservation" and "Routability" are often conflicting goals.  All
   the above goals may sometimes be in conflict with the interests of
   individual end-users or Internet service providers.  Careful analysis
   and judgement is necessary in each individual case to find an
   appropriate compromise.

   The Internet Registry system

      In order to achieve the above goals the Internet Registry (IR)
      hierarchy was established.

      The Internet Registry hierarchy consists of the following levels
      of hierarchy as seen from the top down: IANA, Regional IRs, Local
      IRs.

   IANA

      The Internet Assigned Numbers Authority has authority over all
      number spaces used in the Internet.  This includes Internet
      Address Space. IANA allocates parts of the Internet address space
      to regional IRs according to its established needs.

   Regional IRs

      Regional IRs operate in large geopolitical regions such as
      continents.  Currently there are three regional IRs established;
      InterNIC serving North America, RIPE NCC serving Europe, and AP-
      NIC serving the Asian Pacific region.  Since this does not cover
      all areas, regional IRs also serve areas around its core service
      areas.  It is expected that the number of regional IRs will remain
      relatively small.  Service areas will be of continental
      dimensions.



Hubbard, et. al.         Best Current Practice                  [Page 3]

RFC 2050       Internet Registry IP Allocation Guidelines  November 1996


      Regional IRs are established under the authority of the IANA.
      This requires consensus within the Internet community of the
      region.  A consensus of Internet Service Providers in that region
      may be necessary to fulfill that role.

      The specific duties of the regional IRs include coordination and
      representation of all local IRs in its respective regions.

   Local IRs

      Local IRs are established under the authority of the regional IR
      and IANA.  These local registries have the same role and
      responsibility as the regional registries within its designated
      geographical areas.  These areas are usually of national
      dimensions.

2.  Allocation Framework

2.1  Guidelines for Internet Service Providers (ISPs)

   This document makes a distinction between the allocation of IP
   addresses and the assignment of IP addresses.  Addresses are
   allocated to ISPs by regional registries to assign to its customer
   base.

   ISPs who exchange routing information with other ISPs at multiple
   locations and operate without default routing may request space
   directly from the regional registry in its geographical area.  ISPs
   with no designated regional registry may contact any regional
   registry and the regional registry may either handle the request or
   refer the request to an appropriate registry.

   To facilitate hierarchical addressing, implemented using Classless
   Inter-Domain Routing (CIDR), all other ISPs should request address
   space directly from its upstream provider.  ISPs only request address
   space directly from regional registries if their immediate
   requirement, when satisfied with a contiguous block allocation, has a
   reasonable probability of being routable on the Internet, and they
   meet one or more of the following conditions.

       a)  the ISP is directly connected to a major routing exchange
           (for purposes of this document, a major routing exchange
            is defined as a neutral layer 2 exchange point connecting
            four or more unrelated ISPs.)

       b)  the ISP is multi-homed, that is, it has more than one
           simultaneous connection to the global Internet and no
           connection is favored over the other



Hubbard, et. al.         Best Current Practice                  [Page 4]

RFC 2050       Internet Registry IP Allocation Guidelines  November 1996


   Note that addresses issued directly from the IRs (non-provider
   based), are the least likely to be routable across the Internet.

   The following are the IP allocation guidelines for ISPs:


   1.  CIDR addresses are allocated to ISPs in blocks.  It is
       recommended that those blocks remain intact.  Fragmentation of
       CIDR blocks is discouraged.  More specifically, ISPs are
       encouraged to treat address assignments as loans for the
       duration of the connectivity provision.  At the termination
       of the Internet connectivity contract, e.g., the customer
       moves to another service provider, it is recommended the
       customer return the network addresses currently in use and
       renumber into the new provider's address space.  The ISP
       should allow sufficient time for the renumbering process to be
       completed before the IP addresses are reused.

   2.  To ensure efficient implementation and use of Classless
       Inter-Domain Routing (IDR), the Regional Registries issue
       address space on appropriate "CIDR-supported" bit boundaries.

   3.  ISPs are required to utilize address space in an efficient
       manner.  To this end, ISPs should have documented
       justification available for each assignment.  The regional
       registry may, at any time, ask for this information.  If the
       information is not available, future allocations may be impacted.
       In extreme cases, existing loans may be impacted.

   4.  IP addresses are allocated to ISPs using a slow-start
       procedure.  New ISPs will receive a minimal amount based
       on immediate requirement.  Thereafter,  allocated blocks may be
       increased based on utilization verification supplied to the
       regional registry.  The parent registries are responsible for
       determining appropriate initial and subsequent allocations.
       Additional address allocations will provide enough address space
       to enable the ISP to assign addresses for three months
       without requesting additional address space from its parent
       registry.  Please note that projected customer base has little
       impact on the address allocations made by the parent registries.
       Initial allocation will not be based on any current or future
       routing restrictions but on demonstrated requirements.

   5.  Due to the requirement to increase the utilization efficiency
       of IPv4 address space, all assignments are made with the
       assumption that sites make use of variable length subnet mask
       (VLSM) and classless technologies within their network.  Any
       request for address space based on the use of classfull



Hubbard, et. al.         Best Current Practice                  [Page 5]

RFC 2050       Internet Registry IP Allocation Guidelines  November 1996


       assumptions will require a detailed justification.  The use of
       classfull technologies for the purposes of administrative
       convenience is generally insupportable due to the limited
       availability of free IPv4 address space.

   6.  Regional registries may set a maximum limit on assignment sizes
       such that a second opinion of the regional registry is required.

   7.  Due to constraints on the available free pool of IPv4 address
       space, the use of static IP address assignments (e.g., one
       address per customer) for dial-up users is strongly discouraged.
       While it is understood that the use of static addressing may
       ease some aspects of administration, the current rate of
       consumption of the remaining unassigned IPv4 address space does
       not permit the assignment of addresses for administrative ease.
       Organizations considering the use of static IP address assignment
       are expected to investigate and implement dynamic assignment
       technologies whenever possible.

2.2  Submission of Reassignment Information

   It is imperative that reassignment information be submitted in a
   prompt and efficient manner to facilitate database maintenance and
   ensure database integrity.  Therefore, assignment information must be
   submitted to the regional registry immediately upon making the
   assignment.  The following reasons necessitate transmission of the
   reassignment information:

       a)  to provide operational staff with information on who is using
           the network number and to provide a contact in case of
           operational/security problems,

       b)  to ensure that a provider has exhausted a majority of its
           current CIDR allocation, thereby justifying an additional
           allocation,

       c)  to assist in IP allocation studies.

   Procedures for submitting the reassignment information will be
   determined by each regional registry based on its unique
   requirements.

   All sub-registries (ISPs, Local registries, etc.) must register with
   their respective regional registry to receive information regarding
   reassignment guidelines.  No additional CIDR blocks will be allocated
   by the regional registry or upstream providers until approximately
   80% of all reassignment information has been submitted.




Hubbard, et. al.         Best Current Practice                  [Page 6]

RFC 2050       Internet Registry IP Allocation Guidelines  November 1996


3. Assignment Framework

   An assignment is the delegation of authority over a block of IP
   addresses to an end enterprise.   The end enterprise will use
   addresses from an assignment internally only; it will not sub-
   delegate those addresses.  This section discusses some of the issues
   involved in assignments and the framework behind the assignment of
   addresses.

   In order for the Internet to scale using existing technologies, use
   of regional registry services should be limited to the assignment of
   IP addresses for organizations meeting one or more of the following
   conditions:

      a)  the organization has no intention of connecting to
          the Internet-either now or in the future-but it still
          requires a globally unique IP address.  The organization
          should consider using reserved addresses from RFC1918.
          If it is determined this is not possible, they can be
          issued unique (if not Internet routable) IP addresses.

      b)  the organization is multi-homed with no favored connection.

      c)  the organization's actual requirement for IP space is