home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / rfc / rfc2050 < prev    next >
Text File  |  1996-11-05  |  29KB  |  732 lines

  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                      K. Hubbard
  8. Request for Comments: 2050                                 M. Kosters
  9. Obsoletes: 1466                                              InterNIC
  10. BCP: 12                                                     D. Conrad
  11. Category: Best Current Practice                                 APNIC
  12.                                                         D. Karrenberg
  13.                                                                  RIPE
  14.                                                             J. Postel
  15.                                                                   ISI
  16.                                                         November 1996
  17.  
  18.  
  19.                INTERNET REGISTRY IP ALLOCATION GUIDELINES
  20.  
  21. Status of this Memo
  22.  
  23.    This document specifies an Internet Best Current Practices for the
  24.    Internet Community, and requests discussion and suggestions for
  25.    improvements.  Distribution of this memo is unlimited.
  26.  
  27. IESG Note:
  28.  
  29.    By approving this document as a Best Current Practice,the IESG
  30.    asserts its belief that this policy described herein is an accurate
  31.    representation of the current practice of the IP address registries
  32.    with respect to address assignment.  This does not constitute
  33.    endorsement or recommendation of this policy by the IESG. The IESG
  34.    will reevaluate its approval of this document in December 1997 taking
  35.    into consideration the results of the discussions that will be take
  36.    place in the IRE Working Group between now and then.
  37.  
  38. Abstract
  39.  
  40.    This document describes the registry system for the distribution of
  41.    globally unique Internet address space and registry operations.
  42.    Particularly this document describes the rules and guidelines
  43.    governing the distribution of this address space.
  44.  
  45.    This document describes the IP assignment policies currently used by
  46.    the Regional Registries to implement the guidelines developed by the
  47.    IANA. The guidelines and these policies are subject to revision at
  48.    the direction of the IANA. The registry working group (IRE WG) will
  49.    be discussing these issues and may provide advice to the IANA about
  50.    possible revisions.
  51.  
  52.    This document replaces RFC 1466, with all the guidelines and
  53.    procedures updated and modified in the light of experience.
  54.  
  55.  
  56.  
  57.  
  58. Hubbard, et. al.         Best Current Practice                  [Page 1]
  59.  
  60. RFC 2050       Internet Registry IP Allocation Guidelines  November 1996
  61.  
  62.  
  63.    This document does not describe private Internet address space and
  64.    multicast address space.  It also does not describe regional and
  65.    local refinements of the global rules and guidelines.
  66.  
  67.    This document can be considered the base set of operational
  68.    guidelines in use by all registries.  Additional guidelines may be
  69.    imposed by a particular registry as appropriate.
  70.  
  71. Table of Contents
  72.  
  73.     1.  Introduction.......................................2
  74.     2.  Allocation Framework...............................4
  75.     2.1  Guidelines for Internet Service Providers.........4
  76.     2.2  Submission of Reassignment Information............6
  77.     3.   Assignment Framework..............................7
  78.     3.1  Common Registry Requirements......................7
  79.     3.2  Network Engineering Plans.........................8
  80.     3.3  Previous Assignment History.......................9
  81.     3.4  Network Deployment Plans..........................9
  82.     3.5  Organization Information..........................9
  83.     3.6  Expected Utilization Rate.........................10
  84.     4.   Operational Guidelines for Registries.............10
  85.     5.   In-Addr.Arpa Domain Maintenance...................11
  86.     6.   Right to Appeal...................................11
  87.     7.   References........................................12
  88.     8.   Security Considerations...........................12
  89.     9.   Authors' Addresses................................13
  90.  
  91. 1. Introduction
  92.  
  93.    The addressing constraints described in this document are largely the
  94.    result of the interaction of existing router technology, address
  95.    assignment, and architectural history.  After extensive review and
  96.    discussion, the authors of this document, the IETF working group that
  97.    reviewed it and the IESG have concluded that there are no other
  98.    currently deployable technologies available to overcome these
  99.    limitations. In the event that routing or router technology develops
  100.    to the point that adequate routing aggregation can be achieved by
  101.    other means or that routers can deal with larger routing and more
  102.    dynamic tables, it may be appropriate to review these constraints.
  103.  
  104.    Internet address space is distributed according to the following
  105.    three goals:
  106.  
  107.    1) Conservation: Fair distribution of globally unique Internet address
  108.    space according to the operational needs of the end-users and Internet
  109.    Service Providers operating networks using this address space.
  110.    Prevention of stockpiling in order to maximize the lifetime of the
  111.  
  112.  
  113.  
  114. Hubbard, et. al.         Best Current Practice                  [Page 2]
  115.  
  116. RFC 2050       Internet Registry IP Allocation Guidelines  November 1996
  117.  
  118.  
  119.    Internet address space.
  120.  
  121.    2) Routability: Distribution of globally unique Internet addresses
  122.    in a hierarchical manner, permitting the routing scalability of
  123.    the addresses. This scalability is necessary to ensure proper
  124.    operation of Internet routing, although it must be stressed that
  125.    routability is in no way guaranteed with the allocation or
  126.    assignment of IPv4 addresses.
  127.  
  128.    3) Registration: Provision of a public registry documenting address
  129.    space allocation and assignment.  This is necessary to ensure
  130.    uniqueness and to provide information for Internet trouble shooting
  131.    at all levels.
  132.  
  133.    It is in the interest of the Internet community as a whole that the
  134.    above goals be pursued.  However it should be noted that
  135.    "Conservation" and "Routability" are often conflicting goals.  All
  136.    the above goals may sometimes be in conflict with the interests of
  137.    individual end-users or Internet service providers.  Careful analysis
  138.    and judgement is necessary in each individual case to find an
  139.    appropriate compromise.
  140.  
  141.    The Internet Registry system
  142.  
  143.       In order to achieve the above goals the Internet Registry (IR)
  144.       hierarchy was established.
  145.  
  146.       The Internet Registry hierarchy consists of the following levels
  147.       of hierarchy as seen from the top down: IANA, Regional IRs, Local
  148.       IRs.
  149.  
  150.    IANA
  151.  
  152.       The Internet Assigned Numbers Authority has authority over all
  153.       number spaces used in the Internet.  This includes Internet
  154.       Address Space. IANA allocates parts of the Internet address space
  155.       to regional IRs according to its established needs.
  156.  
  157.    Regional IRs
  158.  
  159.       Regional IRs operate in large geopolitical regions such as
  160.       continents.  Currently there are three regional IRs established;
  161.       InterNIC serving North America, RIPE NCC serving Europe, and AP-
  162.       NIC serving the Asian Pacific region.  Since this does not cover
  163.       all areas, regional IRs also serve areas around its core service
  164.       areas.  It is expected that the number of regional IRs will remain
  165.       relatively small.  Service areas will be of continental
  166.       dimensions.
  167.  
  168.  
  169.  
  170. Hubbard, et. al.         Best Current Practice                  [Page 3]
  171.  
  172. RFC 2050       Internet Registry IP Allocation Guidelines  November 1996
  173.  
  174.  
  175.       Regional IRs are established under the authority of the IANA.
  176.       This requires consensus within the Internet community of the
  177.       region.  A consensus of Internet Service Providers in that region
  178.       may be necessary to fulfill that role.
  179.  
  180.       The specific duties of the regional IRs include coordination and
  181.       representation of all local IRs in its respective regions.
  182.  
  183.    Local IRs
  184.  
  185.       Local IRs are established under the authority of the regional IR
  186.       and IANA.  These local registries have the same role and
  187.       responsibility as the regional registries within its designated
  188.       geographical areas.  These areas are usually of national
  189.       dimensions.
  190.  
  191. 2.  Allocation Framework
  192.  
  193. 2.1  Guidelines for Internet Service Providers (ISPs)
  194.  
  195.    This document makes a distinction between the allocation of IP
  196.    addresses and the assignment of IP addresses.  Addresses are
  197.    allocated to ISPs by regional registries to assign to its customer
  198.    base.
  199.  
  200.    ISPs who exchange routing information with other ISPs at multiple
  201.    locations and operate without default routing may request space
  202.    directly from the regional registry in its geographical area.  ISPs
  203.    with no designated regional registry may contact any regional
  204.    registry and the regional registry may either handle the request or
  205.    refer the request to an appropriate registry.
  206.  
  207.    To facilitate hierarchical addressing, implemented using Classless
  208.    Inter-Domain Routing (CIDR), all other ISPs should request address
  209.    space directly from its upstream provider.  ISPs only request address
  210.    space directly from regional registries if their immediate
  211.    requirement, when satisfied with a contiguous block allocation, has a
  212.    reasonable probability of being routable on the Internet, and they
  213.    meet one or more of the following conditions.
  214.  
  215.        a)  the ISP is directly connected to a major routing exchange
  216.            (for purposes of this document, a major routing exchange
  217.             is defined as a neutral layer 2 exchange point connecting
  218.             four or more unrelated ISPs.)
  219.  
  220.        b)  the ISP is multi-homed, that is, it has more than one
  221.            simultaneous connection to the global Internet and no
  222.            connection is favored over the other
  223.  
  224.  
  225.  
  226. Hubbard, et. al.         Best Current Practice                  [Page 4]
  227.  
  228. RFC 2050       Internet Registry IP Allocation Guidelines  November 1996
  229.  
  230.  
  231.    Note that addresses issued directly from the IRs (non-provider
  232.    based), are the least likely to be routable across the Internet.
  233.  
  234.    The following are the IP allocation guidelines for ISPs:
  235.  
  236.  
  237.    1.  CIDR addresses are allocated to ISPs in blocks.  It is
  238.        recommended that those blocks remain intact.  Fragmentation of
  239.        CIDR blocks is discouraged.  More specifically, ISPs are
  240.        encouraged to treat address assignments as loans for the
  241.        duration of the connectivity provision.  At the termination
  242.        of the Internet connectivity contract, e.g., the customer
  243.        moves to another service provider, it is recommended the
  244.        customer return the network addresses currently in use and
  245.        renumber into the new provider's address space.  The ISP
  246.        should allow sufficient time for the renumbering process to be
  247.        completed before the IP addresses are reused.
  248.  
  249.    2.  To ensure efficient implementation and use of Classless
  250.        Inter-Domain Routing (IDR), the Regional Registries issue
  251.        address space on appropriate "CIDR-supported" bit boundaries.
  252.  
  253.    3.  ISPs are required to utilize address space in an efficient
  254.        manner.  To this end, ISPs should have documented
  255.        justification available for each assignment.  The regional
  256.        registry may, at any time, ask for this information.  If the
  257.        information is not available, future allocations may be impacted.
  258.        In extreme cases, existing loans may be impacted.
  259.  
  260.    4.  IP addresses are allocated to ISPs using a slow-start
  261.        procedure.  New ISPs will receive a minimal amount based
  262.        on immediate requirement.  Thereafter,  allocated blocks may be
  263.        increased based on utilization verification supplied to the
  264.        regional registry.  The parent registries are responsible for
  265.        determining appropriate initial and subsequent allocations.
  266.        Additional address allocations will provide enough address space
  267.        to enable the ISP to assign addresses for three months
  268.        without requesting additional address space from its parent
  269.        registry.  Please note that projected customer base has little
  270.        impact on the address allocations made by the parent registries.
  271.        Initial allocation will not be based on any current or future
  272.        routing restrictions but on demonstrated requirements.
  273.  
  274.    5.  Due to the requirement to increase the utilization efficiency
  275.        of IPv4 address space, all assignments are made with the
  276.        assumption that sites make use of variable length subnet mask
  277.        (VLSM) and classless technologies within their network.  Any
  278.        request for address space based on the use of classfull
  279.  
  280.  
  281.  
  282. Hubbard, et. al.         Best Current Practice                  [Page 5]
  283.  
  284. RFC 2050       Internet Registry IP Allocation Guidelines  November 1996
  285.  
  286.  
  287.        assumptions will require a detailed justification.  The use of
  288.        classfull technologies for the purposes of administrative
  289.        convenience is generally insupportable due to the limited
  290.        availability of free IPv4 address space.
  291.  
  292.    6.  Regional registries may set a maximum limit on assignment sizes
  293.        such that a second opinion of the regional registry is required.
  294.  
  295.    7.  Due to constraints on the available free pool of IPv4 address
  296.        space, the use of static IP address assignments (e.g., one
  297.        address per customer) for dial-up users is strongly discouraged.
  298.        While it is understood that the use of static addressing may
  299.        ease some aspects of administration, the current rate of
  300.        consumption of the remaining unassigned IPv4 address space does
  301.        not permit the assignment of addresses for administrative ease.
  302.        Organizations considering the use of static IP address assignment
  303.        are expected to investigate and implement dynamic assignment
  304.        technologies whenever possible.
  305.  
  306. 2.2  Submission of Reassignment Information
  307.  
  308.    It is imperative that reassignment information be submitted in a
  309.    prompt and efficient manner to facilitate database maintenance and
  310.    ensure database integrity.  Therefore, assignment information must be
  311.    submitted to the regional registry immediately upon making the
  312.    assignment.  The following reasons necessitate transmission of the
  313.    reassignment information:
  314.  
  315.        a)  to provide operational staff with information on who is using
  316.            the network number and to provide a contact in case of
  317.            operational/security problems,
  318.  
  319.        b)  to ensure that a provider has exhausted a majority of its
  320.            current CIDR allocation, thereby justifying an additional
  321.            allocation,
  322.  
  323.        c)  to assist in IP allocation studies.
  324.  
  325.    Procedures for submitting the reassignment information will be
  326.    determined by each regional registry based on its unique
  327.    requirements.
  328.  
  329.    All sub-registries (ISPs, Local registries, etc.) must register with
  330.    their respective regional registry to receive information regarding
  331.    reassignment guidelines.  No additional CIDR blocks will be allocated
  332.    by the regional registry or upstream providers until approximately
  333.    80% of all reassignment information has been submitted.
  334.  
  335.  
  336.  
  337.  
  338. Hubbard, et. al.         Best Current Practice                  [Page 6]
  339.  
  340. RFC 2050       Internet Registry IP Allocation Guidelines  November 1996
  341.  
  342.  
  343. 3. Assignment Framework
  344.  
  345.    An assignment is the delegation of authority over a block of IP
  346.    addresses to an end enterprise.   The end enterprise will use
  347.    addresses from an assignment internally only; it will not sub-
  348.    delegate those addresses.  This section discusses some of the issues
  349.    involved in assignments and the framework behind the assignment of
  350.    addresses.
  351.  
  352.    In order for the Internet to scale using existing technologies, use
  353.    of regional registry services should be limited to the assignment of
  354.    IP addresses for organizations meeting one or more of the following
  355.    conditions:
  356.  
  357.       a)  the organization has no intention of connecting to
  358.           the Internet-either now or in the future-but it still
  359.           requires a globally unique IP address.  The organization
  360.           should consider using reserved addresses from RFC1918.
  361.           If it is determined this is not possible, they can be
  362.           issued unique (if not Internet routable) IP addresses.
  363.  
  364.       b)  the organization is multi-homed with no favored connection.
  365.  
  366.       c)  the organization's actual requirement for IP space is
  367.           very large, for example, the network prefix required to
  368.           cover the request is of length /18 or shorter.
  369.  
  370.    All other requestors should contact its ISP for address space or
  371.    utilize the addresses reserved for non-connected networks described
  372.    in RFC1918 until an Internet connection is established.  Note that
  373.    addresses issued directly from the IRs,(non-provider based), are the
  374.    least likely to be routable across the Internet.
  375.  
  376. 3.1  Common Registry Requirements
  377.  
  378.    Because the number of available IP addresses on the Internet is
  379.    limited, the utilization rate of address space will be a key factor
  380.    in network number assignment.  Therefore, in the best interest of the
  381.    Internet as a whole, specific guidelines have been created to govern
  382.    the assignment of addresses based on utilization rates.
  383.  
  384.    Although topological issues may make exceptions necessary, the basic
  385.    criteria that should be met to receive network numbers are listed
  386.    below:
  387.  
  388.                 25% immediate utilization rate
  389.                 50% utilization  rate within 1 year
  390.  
  391.  
  392.  
  393.  
  394. Hubbard, et. al.         Best Current Practice                  [Page 7]
  395.  
  396. RFC 2050       Internet Registry IP Allocation Guidelines  November 1996
  397.  
  398.  
  399.    The utilization rate above is to be used as a guideline, there may be
  400.    be occasions when the 1 year rate does not fall exactly in this
  401.    range.  Organizations must exhibit a high confidence level in its 1
  402.    year utilization rate and supply documentation to justify the level
  403.    of confidence.
  404.  
  405.    Organizations will be assigned address space based on immediate
  406.    utilization plus 1 year projected utilization.  A prefix longer than
  407.    /24 may be issued if deemed appropriate.  Organizations with less
  408.    than 128 hosts will not be issued an IP address directly from the
  409.    IRs.  Organizations may be issued a prefix longer than /24 if the
  410.    organization can provide documentation from a registry recognized ISP
  411.    indicating the ISP will accept the long prefix for injection into the
  412.    global routing system.
  413.  
  414.    Exceptions to the criteria will not be made based on insufficient
  415.    equipment without additional detailed justification.  Organizations
  416.    should implement variable length subnet mask (VLSM) internally to
  417.    maximize the effective utilization of address space.  Address
  418.    assignments will be made under the assumption that VLSM is or will be
  419.    implemented.
  420.  
  421.    IP addresses are valid as long as the criteria continues to be met.
  422.    The IANA reserves the right to invalidate any IP assignments once it
  423.    is determined the the requirement for the address space no longer
  424.    exists.  In the event of address invalidation, reasonable efforts
  425.    will be made by the appropriate registry to inform the organization
  426.    that the addresses have been returned to the free pool of IPv4
  427.    address space.
  428.  
  429. 3.2  Network Engineering Plans
  430.  
  431.    Before a registry makes an assignment, it must examine each address
  432.    space request in terms of the requesting organization's networking
  433.    plans.  These plans should be documented, and the following
  434.    information should be included:
  435.  
  436.       1.  subnetting plans, including subnet masks and number of
  437.           hosts on each subnet for at least one year
  438.  
  439.       2.  a description of the network topology
  440.  
  441.       3.  a description of the network routing plans, including the
  442.           routing protocols to be used as well as any limitations.
  443.  
  444.  
  445.  
  446.  
  447.  
  448.  
  449.  
  450. Hubbard, et. al.         Best Current Practice                  [Page 8]
  451.  
  452. RFC 2050       Internet Registry IP Allocation Guidelines  November 1996
  453.  
  454.  
  455.    The subnetting plans should include:
  456.  
  457.       a)  a tabular listing of all subnets on the network
  458.  
  459.       b)  its associated subnet masks
  460.  
  461.       c)  the estimated number of hosts
  462.  
  463.       d)  a brief descriptive remark regarding the subnet.
  464.  
  465.    If subnetting is not being used, an explanation why it cannot be
  466.    implemented is required.  Care must be taken to ensure that the host
  467.    and subnet estimates correspond to realistic requirements and are not
  468.    based on administrative convenience.
  469.  
  470. 3.3  Previous Assignment History
  471.  
  472.    To promote increased usage of address space, the registries will
  473.    require an accounting of address space previously assigned to the
  474.    enterprise, if any.  In the context of address space allocation, an
  475.    "enterprise" consists of all divisions and/or subsidiaries falling
  476.    under a common parent organization.  The previous assignment history
  477.    should include all network numbers assigned to the organization, plus
  478.    the network masks for those networks and the number of hosts on each
  479.    (sub-)network.  Sufficient corroborating evidence should be provided
  480.    to allow the assigning registry to be confident that the network
  481.    descriptions provided are accurate.  Routing table efficiency will be
  482.    taken into account by the regional registries and each request will
  483.    be handled on a case by case basis.
  484.  
  485. 3.4  Network Deployment Plans
  486.  
  487.    In order to assign an appropriate amount of space in the required
  488.    time frame, a registry may request deployment plans for a network.
  489.    Deployment plans should include the number of hosts to be deployed
  490.    per time period, expected network growth during that time period, and
  491.    changes in the network topology that describe the growth.
  492.  
  493. 3.5  Organization Information
  494.  
  495.    A registry may request that an organization furnish a published
  496.    description verifying that the organization is what it claims to be.
  497.    This information can consist of brochures, documents of
  498.    incorporation, or similar published material.
  499.  
  500.  
  501.  
  502.  
  503.  
  504.  
  505.  
  506. Hubbard, et. al.         Best Current Practice                  [Page 9]
  507.  
  508. RFC 2050       Internet Registry IP Allocation Guidelines  November 1996
  509.  
  510.  
  511. 3.6  Expected Utilization Rate
  512.  
  513.    As stated in the foregoing text, one of the key factors in
  514.    determining how much address space is appropriate for an organization
  515.    is the expected utilization rate of the network.  The expected
  516.    utilization rate is the number of hosts connected to the network
  517.    divided by the total number of hosts possible on the network.  In
  518.    addition, the estimated number of hosts should be projected over a
  519.    reasonable time frame, i.e., one in which the requesting enterprise
  520.    has a high level of confidence.  The minimal utilization rate is set
  521.    by the IANA and may be changed at any time.  New utilization rates
  522.    may be enforced by the regional registries prior to updating the
  523.    written policy.
  524.  
  525. 4.  Operational Guidelines For Registries
  526.  
  527.    1.  Regional Registries provide registration services as its
  528.        primary function.  Therefore, regional registries may charge some
  529.        fee for services rendered, generally in relation to the cost of
  530.        providing those services.
  531.  
  532.    2.  Regardless of the source of its address space, sub-registries
  533.        (Local IRs, ISPs, etc.) must adhere to the guidelines of its
  534.        regional registry.  In turn, it must also ensure that its
  535.        customers follow those guidelines.
  536.  
  537.    3.  To maximize the effective use of address space, IP addresses need
  538.        to be assigned/allocated in classless blocks.  With this in mind,
  539.        assignments will not be made in Class Cs or Bs but by prefix
  540.        length.  Consequently, an organization that would have been
  541.        assigned a Class B in the past will now be assigned a /16 prefix,
  542.        regardless of the actual address class.
  543.  
  544.    4.  All IP address requests are subject to audit and verification
  545.        by any means deemed appropriate by the regional registry.
  546.        If any assignment is found to be based on false information,
  547.        the registry may invalidate the request and return the
  548.        assigned addresses back to the pool of free addresses for
  549.        later assignment.
  550.  
  551.    5.  Due to technical and implementation constraints on the Internet
  552.        routing system and the possibility of routing overload, major
  553.        transit providers may need to impose certain restrictions to
  554.        reduce the number of globally advertised routes.  This may
  555.        include setting limits on the size of CIDR prefixes added to
  556.        the routing tables, filtering of non-aggregated routes, etc.
  557.        Therefore, addresses obtained directly from regional registry
  558.        (provider-independent, also known as portable) are not
  559.  
  560.  
  561.  
  562. Hubbard, et. al.         Best Current Practice                 [Page 10]
  563.  
  564. RFC 2050       Internet Registry IP Allocation Guidelines  November 1996
  565.  
  566.  
  567.        guaranteed routable on the Internet.
  568.  
  569.    6.  Information provided to request address space is often considered
  570.        sensitive by the requesting  organization.  The assigning
  571.        registry must treat as confidential any and all information
  572.        that the requesting organization specifically indicates as
  573.        sensitive.  When a requesting organization does not have
  574.        assurance of privacy, the parent of the assigning registry may
  575.        be required to do the assignment.  In such cases, the parent
  576.        registry will provide the assigning registry with information
  577.        regarding the appropriate amount of address space to allocate.
  578.  
  579.    7.  The transfer of IP addresses from one party to another must be
  580.        approved by the regional registries.  The party trying to obtain
  581.        the IP address must meet the same criteria as if they were
  582.        requesting an IP address directly from the IR.
  583.  
  584. 5.  In-ADDR.ARPA Domain Maintenance
  585.  
  586.    The regional registries will be responsible for maintaining IN-
  587.    ADDR.ARPA records only on the parent blocks of IP addresses issued
  588.    directly to the ISPs or those CIDR blocks of less than /16.  Local
  589.    IRs/ISPs with a prefix length of /16 or shorter will be responsible
  590.    for maintaining all IN-ADDR.ARPA resource records for its customers.
  591.  
  592.    IN-ADDR.ARPA resource records for networks not associated with a
  593.    specific provider will continue to be maintained by the regional
  594.    registry.
  595.  
  596. 6.  Right to Appeal
  597.  
  598.    If an organization feels that the registry that assigned its address
  599.    has not performed its task in the requisite manner, the organization
  600.    has the right of appeal to the parent registry.
  601.  
  602.    In such cases, the assigning registry shall make available all
  603.    relevant documentation to the parent registry, and the decision of
  604.    the parent registry shall be considered final (barring additional
  605.    appeals to the parent registry's parent).  If necessary, after
  606.    exhausting all other avenues, the appeal may be forwarded to IANA for
  607.    a final decision.  Each registry must, as part of their policy,
  608.    document and specify how to appeal a registry assignment decision.
  609.  
  610.  
  611.  
  612.  
  613.  
  614.  
  615.  
  616.  
  617.  
  618. Hubbard, et. al.         Best Current Practice                 [Page 11]
  619.  
  620. RFC 2050       Internet Registry IP Allocation Guidelines  November 1996
  621.  
  622.  
  623. 7.  References
  624.  
  625.    [RFC 1519] Fuller, V., Li, T., Yu, J., and K. Varadhan,
  626.       "Classless Inter- Domain Routing (CIDR): an Address
  627.       Assignment and Aggregation Strategy", September 1993.
  628.  
  629.    [RFC 1518] Rekhter, Y., and T. Li, "An Architecture for IP
  630.       Address Allocation with CIDR", September 1993.
  631.  
  632.    [RFC 1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., and
  633.       G. de Groot, "Address Allocation for Private Internets",
  634.       February 1996.
  635.  
  636.    [RFC 1814] Gerich, E., "Unique Addresses are Good", June 1995.
  637.  
  638.    [RFC 1900] Carpenter, B., and Y. Rekhter, "Renumbering Needs Work",
  639.       February 1996.
  640.  
  641. 8. Security Considerations
  642.  
  643.    Security issues are not discussed in this memo.
  644.  
  645.  
  646.  
  647.  
  648.  
  649.  
  650.  
  651.  
  652.  
  653.  
  654.  
  655.  
  656.  
  657.  
  658.  
  659.  
  660.  
  661.  
  662.  
  663.  
  664.  
  665.  
  666.  
  667.  
  668.  
  669.  
  670.  
  671.  
  672.  
  673.  
  674. Hubbard, et. al.         Best Current Practice                 [Page 12]
  675.  
  676. RFC 2050       Internet Registry IP Allocation Guidelines  November 1996
  677.  
  678.  
  679. 9. Authors' Addresses
  680.  
  681.    Kim Hubbard
  682.    InterNIC Registration Services
  683.    c/o Network Solutions
  684.    505 Huntmar Park Drive
  685.    Herndon, VA 22070
  686.  
  687.    Phone: (703) 742-4870
  688.    EMail: kimh@internic.net
  689.  
  690.    Mark Kosters
  691.    InterNIC Registration Services
  692.    c/o Network Solutions
  693.    505 Huntmar Park Drive
  694.    Herndon, VA 22070
  695.  
  696.    Phone: (703) 742-4795
  697.    EMail: markk@internic.net
  698.  
  699.    David Conrad
  700.    Asia Pacific Network Information Center
  701.    c/o United Nations University
  702.    53-70 Jingumae 5-chome,
  703.    Shibuya-ku, Tokyo 150
  704.    JP
  705.  
  706.    Phone: +81-3-5467-7014
  707.    EMail: davidc@APNIC.NET
  708.  
  709.    Daniel Karrenberg
  710.    RIPE NCC
  711.    Kruislaan 409
  712.    SJ Amsterdam NL-1098
  713.    NL
  714.  
  715.    Phone: +31 20 592 5065
  716.    EMail: dfk@RIPE.NET
  717.  
  718.    Jon Postel
  719.    USC/Information Sciences Institute
  720.    4676 Admiralty Way
  721.    Marina del Rey, CA  90292
  722.  
  723.    Phone: 310-822-1511
  724.    EMail: Postel@ISI.EDU
  725.  
  726.  
  727.  
  728.  
  729.  
  730. Hubbard, et. al.         Best Current Practice                 [Page 13]
  731.  
  732.