INTERNET-DRAFT
                                                      K. Hubbard
                                                      InterNIC
                                                      M. Kosters
                                                      InterNIC
                                                      D. Conrad
                                                      APNIC
                                                      D. Karrenberg
                                                      RIPE
                                                      J.Postel
                                                      IANA
                                                      June 1996
 
 
                INTERNET REGISTRY IP ALLOCATION GUIDELINES
                 draft-hubbard-registry-guidelines-02.txt
 
 
 Status of this Memo
 
    "This memo provides information for the Internet community.  This
    memo does not specify an Internet standard of any kind.  Distribution
    of this memo is unlimited."
 
    This document is an Internet Draft.  Internet Drafts are working
    documents of the Internet Engineering Task Force (IETF), its Areas,
    and its Working Groups.  Note that other groups may also distribute
    working documents as Internet Drafts.
 
    Internet Drafts are draft documents valid for a maximum of six
    months.  Internet Drafts may be updated, replaced, or obsoleted by
    other documents at any time.  It is not appropriate to use Internet
    Drafts as reference material or to cite them other than as a
    ``working draft'' or ``work in progress.''
 
    To learn the current status of any Internet-Draft, please check the
    ``1id-abstracts.txt'' listing contained in the Internet- Drafts
    Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
    munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
    ftp.isi.edu (US West Coast).
 
 
 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 replaces RFC 1466, with all the guidelines and
 procedures updated and modified in the light of experience.
 
 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.
 
 
 
 
 
 
 
 
 
 
 Expiration Date 6 Mos.                                          [Page 1]


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


 INTERNET-DRAFT                                                 June 1996
 
 
                             1. Introduction
 
 The registry procedures described in this document are largely defined by
 the nature and limitations of current routing and router technology.  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,
 different registry procedures may become appropriate.
 
 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
 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.
 
 
 
 Expiration Date 6 Mos.                                          [Page 3]


 INTERNET-DRAFT                                                 June 1996
 
 
 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.
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 Expiration Date 6 Mos.                                          [Page 4]


 INTERNET-DRAFT                                                 June 1996
 
 
 Regional IRs are established under the authority of the IANA.  This
 requires consensus within the Internet community of the region.  A con-
 sensus 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 loca-
 tions 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 probabil-
 ity 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
 
    Note that addresses issued directly from the IRs, (non-provider
 
 
 
 Expiration Date 6 Mos.                                          [Page 5]


 INTERNET-DRAFT                                                 June 1996
 
 
 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 (CIDR), 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
        assumptions will require a detailed justification.  The use of
 
 
 
 Expiration Date 6 Mos.                                          [Page 6]


 INTERNET-DRAFT                                                 June 1996
 
 
        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.
 
                         3. Assignment Framework
 
 
 
 
 Expiration Date 6 Mos.                                          [Page 7]


 INTERNET-DRAFT                                                 June 1996
 
 
 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 condi-
 tions:
 
       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
           very large, for example, the network prefix required to
           cover the request is of length /18 or shorter.
 
  All other requestors should contact its ISP for address
  space or utilize the addresses reserved for non-connected networks
  described in RFC1918 until an Internet connection is established.
  Note that addresses issued directly from the IRs,(non-provider based),
  are the least likely to be routable across the Internet.
 
 3.1  Common Registry Requirements
 
 Because the number of available IP addresses on the Internet is limited,
 the utilization rate of address space will be a key factor in network
 number assignment.  Therefore, in the best interest of the Internet as a
 whole, specific guidelines have been created to govern the assignment of
 addresses based on utilization rates.
 
 Although topological issues may make exceptions necessary, the basic
 criteria that should be met to receive network numbers are listed below:
 
                 25% immediate utilization rate
                 50% utilization  rate within 1 year
 
 The utilization rate above is to be used as a guideline, there may be be
 occasions when the 1 year rate does not fall exactly in this range.
 Organizations must exhibit a high confidence level in its 1 year utili-
 zation rate and supply documentation to justify the level of confidence.
 
 
 
 Expiration Date 6 Mos.                                          [Page 8]


 INTERNET-DRAFT                                                 June 1996
 
 
 Organizations will be assigned address space based on immediate utiliza-
 tion plus 1 year projected utilization.  A prefix longer than /24 may be
 issued if deemed appropriate.  Organizations with less than 128 hosts
 will not be issued an IP address directly from the IRs.  Organizations
 may be issued a prefix longer than /24 if the organization can provide
 documentation from a registry recognized ISP indicating the ISP will
 accept the long prefix for injection into the global routing system.
 
 Exceptions to the criteria will not be made based on insufficient equip-
 ment without additional detailed justification.  Organizations should
 implement variable length subnet mask (VLSM) internally to maximize the
 effective utilization of address space.  Address assignments will be
 made under the assumption that VLSM is or will be implemented.
 
 IP addresses are valid as long as the criteria continues to be met. The
 IANA reserves the right to invalidate any IP assignments once it is
 determined the the requirement for the address space no longer exists.
 In the event of address invalidation, reasonable efforts will be made by
 the appropriate registry to inform the organization that the addresses
 have been returned to the free pool of IPv4 address space.
 
 3.2  Network Engineering Plans
 
 Before a registry makes an assignment, it must examine each address
 space request in terms of the requesting organization's networking
 plans.  These plans should be documented, and the following information
 should be included:
 
       1.  subnetting plans, including subnet masks and number of
           hosts on each subnet for at least one year
 
       2.  a description of the network topology
 
       3.  a description of the network routing plans, including the
           routing protocols to be used as well as any limitations.
 
  The subnetting plans should include:
 
       a)  a tabular listing of all subnets on the network
 
       b)  its associated subnet masks
 
       c)  the estimated number of hosts
 
       d)  a brief descriptive remark regarding the subnet.
 
 If subnetting is not being used, an explanation why it cannot be imple-
 mented is required.  Care must be taken to ensure that the host and
 
 
 
 Expiration Date 6 Mos.                                          [Page 9]


 INTERNET-DRAFT                                                 June 1996
 
 
 subnet estimates correspond to realistic requirements and are not based
 on administrative convenience.
 
 3.3  Previous Assignment History
 
 To promote increased usage of address space, the registries will require
 an accounting of address space previously assigned to the enterprise, if
 any.  In the context of address space allocation, an "enterprise" con-
 sists of all divisions and/or subsidiaries falling under a common parent
 organization.  The previous assignment history should include all net-
 work numbers assigned to the organization, plus the network masks for
 those networks and the number of hosts on each (sub-)network.  Suffi-
 cient corroborating evidence should be provided to allow the assigning
 registry to be confident that the network descriptions provided are
 accurate.  Routing table efficiency will be taken into account by the
 regional registries and each request will be handled on a case by case
 basis.
 
 
 3.4  Network Deployment Plans
 
 In order to assign an appropriate amount of space in the required time
 frame, a  registry  may request deployment plans for a network.  Deploy-
 ment plans should include the number of hosts to be deployed per time
 period, expected network growth during that time period, and changes in
 the network topology that describe the growth.
 
 3.5  Organization Information
 
 A registry may request that an organization furnish a published descrip-
 tion verifying that the organization is what it claims to be.  This
 information can consist of brochures, documents of incorporation, or
 similar published material.
 
 3.6  Expected Utilization Rate
 
 As stated in the foregoing text, one of the key factors in determining
 how much address space is appropriate for an organization is the
 expected utilization rate of the network.  The expected utilization rate
 is the number of hosts connected to the network divided by the total
 number of hosts possible on the network.  In addition, the estimated
 number of hosts should be projected over a reasonable time frame, i.e.,
 one in which the requesting enterprise has a high level of confidence.
 The minimal utilization rate is set by the IANA and may be changed at
 any time.  New utilization rates may be enforced by the regional regis-
 tries prior to updating the written policy.
 
 
 
 
 
 Expiration Date 6 Mos.                                         [Page 10]


 INTERNET-DRAFT                                                 June 1996
 
 
                4.  Operational Guidelines For Registries
 
 1.     Regional Registries provide registration services as its
        primary function.  Therefore, regional registries may charge some
        fee for services rendered, generally in relation to the cost of
        providing those services.
 
 2.     Regardless of the source of its address space, sub-registries
        (Local IRs, ISPs, etc.) must adhere to the guidelines of its
        regional registry.  In turn, it must also ensure that its
        customers follow those guidelines.
 
 3.     To maximize the effective use of address space, IP addresses need
        to be assigned/allocated in classless blocks.  With this in mind,
        assignments will not be made in Class Cs or Bs but by prefix
        length.  Consequently, an organization that would have been
        assigned a Class B in the past will now be assigned a /16 prefix,
        regardless of the actual address class.
 
 4.     All IP address requests are subject to audit and verification
        by any means deemed appropriate by the regional registry.
        If any assignment is found to be based on false information,
        the registry may invalidate the request and return the
        assigned addresses back to the pool of free addresses for
        later assignment.
 
 5.     Due to technical and implementation constraints on the Internet
        routing system and the possibility of routing overload, major
        transit providers may need to impose certain restrictions to
        reduce the number of globally advertised routes.  This may
        include setting limits on the size of CIDR prefixes added to
        the routing tables, filtering of non-aggregated routes, etc.
        Therefore, addresses obtained directly from regional registry
        (provider-independent, also known as portable) are not
        guaranteed routable on the Internet.
 
 6.     Information provided to request address space is often considered
        sensitive by the requesting  organization.  The assigning
        registry must treat as confidential any and all information
        that the requesting organization specifically indicates as
        sensitive.  When a requesting organization does not have
        assurance of privacy, the parent of the assigning registry may
        be required to do the assignment.  In such cases, the parent
        registry will provide the assigning registry with information
        regarding the appropriate amount of address space to allocate.
 
 7.    The transfer of IP addresses from one party to another must be
       approved by the regional registries.  The party trying to obtain
 
 
 
 Expiration Date 6 Mos.                                         [Page 11]


 INTERNET-DRAFT                                                 June 1996
 
 
       the IP address must meet the same criteria as if they were
       requesting an IP address directly from the IR.
 
                   5.  In-ADDR.ARPA Domain Maintenance
 
 The regional registries will be responsible for maintaining IN-ADDR.ARPA
 records only on the parent blocks of IP addresses issued directly to the
 ISPs or those CIDR blocks of less than /16.  Local IRs/ISPs with a pre-
 fix length of /16 or shorter will be responsible for maintaining all
 IN-ADDR.ARPA resource records for its customers.
 
 IN-ADDR.ARPA resource records for networks not associated with a
 specific provider will continue to be maintained by the regional regis-
 try.
 
                           6.  Right to Appeal
 If an organization feels that the registry that assigned its address has
 not performed its task in the requisite manner, the organization has the
 right of appeal to the parent registry.
 
 In such cases, the assigning registry shall make available all relevant
 documentation to the parent registry, and the decision of the parent
 registry shall be considered final (barring additional appeals to the
 parent registry's parent).  If necessary, after exhausting all other
 avenues, the appeal may be forwarded to IANA for a final decision.  Each
 registry must, as part of their policy, document and specify how to
 appeal a registry assignment decision.
 
 
                              7.  References
 
 [RFC 1519] V. Fuller, T. Li, J. Yu, K. Varadhan,
    "Classless Inter- Domain Routing (CIDR): an Address
    Assignment and Aggregation Strategy".
 
 [RFC 1518] Y. Rekhter, T. Li, "An Architecture for IP
    Address Allocation with CIDR".
 
 [RFC 1918] Y. Rekhter, B. Moskowitz, D. Karrenberg, G. de Groot,
  "Address Allocation for Private Internets".
 
 [RFC 1814] E. Gerich, "Unique Addresses are Good"
 
 [RFC 1900] B. Carpenter, Y. Rekhter, "Renumbering Needs Work"
 
 
 
 
 
 
 
 Expiration Date 6 Mos.                                         [Page 12]


 INTERNET-DRAFT                                                 June 1996
 
 
 8. Authors' Addresses
 
     Kim Hubbard
     InterNIC Registration Services
     c/o Network Solutions
     505 Huntmar Park Drive
     Herndon, VA 22070
     Phone: (703) 742-4870
     email: kimh@internic.net
 
     Jon Postel
     USC/Information Sciences Institute
     4676 Admiralty Way
     Marina del Rey, CA  90292
     Phone: 310-822-1511
     EMail: Postel@ISI.EDU
 
     Mark Kosters
     InterNIC Registration Services
     c/o Network Solutions
     505 Huntmar Park Drive
     Herndon, VA 22070
     Phone: (703) 742-4795
     email: markk@internic.net
 
     David Conrad
     Asia Pacific Network Information Center
     c/o United Nations University
     53-70 Jingumae 5-chome,
     Shibuya-ku, Tokyo 150
     JP
     Phone: +81-3-5467-7014
     email: davidc@APNIC.NET
 
     Daniel Karrenberg
     RIPE NCC
     Kruislaan 409
     SJ Amsterdam NL-1098
     NL
     Phone: +31 20 592 5065
     email: dfk@RIPE.NET
 
 
 
 
 
 
 
 
 
 
 Expiration Date 6 Mos.                                         [Page 13]