GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc7020

Internet Engineering Task Force (IETF) R. Housley Request for Comments: 7020 Vigil Security Obsoletes: 2050 J. Curran Category: Informational ARIN ISSN: 2070-1721 G. Huston

                                                                 APNIC
                                                             D. Conrad
                                                      Virtualized, LLC
                                                           August 2013
                The Internet Numbers Registry System

Abstract

 This document provides information about the current Internet Numbers
 Registry System used in the distribution of globally unique Internet
 Protocol (IP) address space and autonomous system (AS) numbers.
 This document also provides information about the processes for
 further evolution of the Internet Numbers Registry System.
 This document replaces RFC 2050.
 This document does not propose any changes to the current Internet
 Numbers Registry System.  Rather, it documents the Internet Numbers
 Registry System as it works today.

Status of This Memo

 This document is not an Internet Standards Track specification; it is
 published for informational purposes.
 This document is a product of the Internet Engineering Task Force
 (IETF).  It represents the consensus of the IETF community.  It has
 received public review and has been approved for publication by the
 Internet Engineering Steering Group (IESG).  Not all documents
 approved by the IESG are a candidate for any level of Internet
 Standard; see Section 2 of RFC 5741.
 Information about the current status of this document, any errata,
 and how to provide feedback on it may be obtained at
 http://www.rfc-editor.org/info/rfc7020.

Housley, et al. Informational [Page 1] RFC 7020 Internet Registry System August 2013

Copyright Notice

 Copyright (c) 2013 IETF Trust and the persons identified as the
 document authors.  All rights reserved.
 This document is subject to BCP 78 and the IETF Trust's Legal
 Provisions Relating to IETF Documents
 (http://trustee.ietf.org/license-info) in effect on the date of
 publication of this document.  Please review these documents
 carefully, as they describe your rights and restrictions with respect
 to this document.  Code Components extracted from this document must
 include Simplified BSD License text as described in Section 4.e of
 the Trust Legal Provisions and are provided without warranty as
 described in the Simplified BSD License.

Table of Contents

 1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 2
 2.  Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
 3.  Internet Numbers Registry System Structure  . . . . . . . . . . 3
 4.  Internet Numbers Registry Technical Considerations  . . . . . . 5
 5.  Internet Numbers Registry Evolution . . . . . . . . . . . . . . 5
 6.  Summary of Changes since RFC 2050 . . . . . . . . . . . . . . . 6
 7.  Security Considerations . . . . . . . . . . . . . . . . . . . . 6
 8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 7
 9.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 7
   9.1.  Normative References  . . . . . . . . . . . . . . . . . . . 7
   9.2.  Informative References  . . . . . . . . . . . . . . . . . . 8

1. Introduction

 The administrative structures of the Internet Numbers Registry System
 described in this document are largely the result of the interaction
 of operational practices, existing routing technology, number
 resource assignments that have occurred over time, and network
 architectural history.  Further discussion and analysis of these
 interactions are outside the scope of this document.
 This document provides information about the current Internet Numbers
 Registry System used in the distribution of globally unique Internet
 Protocol (IP) address space and autonomous system (AS) numbers.  It
 also describes the processes used for further evolution of the
 Internet Numbers Registry System.  This document does not propose any
 changes to the current operation of this system.
 This document replaces RFC 2050.  Since the publication of RFC 2050,
 the Internet Numbers Registry System has changed significantly.  This
 document describes the present Internet Numbers Registry System.

Housley, et al. Informational [Page 2] RFC 7020 Internet Registry System August 2013

2. Goals

 Internet number resources are currently distributed according to the
 following (non-exclusive) goals:
 1)  Allocation Pool Management: Due to the fixed lengths of IP
     addresses and AS numbers, the pools from which these resources
     are allocated are finite.  As such, allocations must be made in
     accordance with the operational needs of those running the
     networks that make use of these number resources and by taking
     into consideration pool limitations at the time of allocation.
 2)  Hierarchical Allocation: Given current routing technology, the
     distribution of IP addresses in a hierarchical manner increases
     the likelihood of continued scaling of the Internet's routing
     system.  As such, it is currently a goal to allocate IP addresses
     in such a way that permits aggregation of these addresses into a
     minimum number of routing announcements.  However, whether IP
     addresses are actually announced to the Internet and the manner
     of their advertisement into the Internet's routing system are
     operational considerations outside the scope of the Internet
     Numbers Registry System.
 3)  Registration Accuracy: A core requirement of the Internet Numbers
     Registry System is to maintain a registry of allocations to
     ensure uniqueness and to provide accurate registration
     information of those allocations in order to meet a variety of
     operational requirements.  Uniqueness ensures that IP addresses
     and AS numbers are not allocated to more than one party at the
     same time.
 These goals may sometimes conflict with each other or with the
 interests of individual end users, Internet service providers, or
 other number resource consumers.  Careful analysis, judgment, and
 cooperation among registry system providers and consumers at all
 levels via community-developed policies are necessary to find
 appropriate compromises to facilitate Internet operations.

3. Internet Numbers Registry System Structure

 The Internet Registry (IR) hierarchy was established to provide for
 the allocation of IP addresses and AS numbers with consideration to
 the above goals.  This hierarchy is rooted in the Internet Assigned
 Numbers Authority (IANA) address allocation function, which serves a
 set of "Regional Internet Registries" (RIRs); the RIRs then serve a
 set of "Local Internet Registries" (LIRs) and other customers.  LIRs
 in turn serve their respective number resource consumers (which may
 be themselves, their customers, "sub-LIRs", etc.)

Housley, et al. Informational [Page 3] RFC 7020 Internet Registry System August 2013

 IETF
    The IETF specifies the underlying technical facilities and
    constraints of Internet numbers administered by the Internet
    Numbers Registry System.  These specifications are aimed at
    enabling and protecting the long-term viability of the Internet,
    and adjustments to those specifications are made over time as
    circumstances warrant.  The IETF has also reserved portions of the
    Internet number spaces and identifiers for future needs.
 IANA
    The Internet Assigned Numbers Authority (IANA) is a role, not an
    organization.  For the Internet Numbers Registry System, the IANA
    role manages the top of the IP address and AS number allocation
    hierarchies.  The Internet Corporation for Assigned Names and
    Numbers (ICANN) currently fulfills the IANA role in accordance
    with the IETF-ICANN "Memorandum of Understanding Concerning
    Technical Work of the Internet Assigned Numbers Authority", which
    was signed and ratified in March 2000 [RFC2860].  In addition,
    ICANN performs the IANA services related to the IP address space
    and AS numbers according to global number resource policies that
    have been developed by the community and formalized under a
    Memorandum of Understanding between ICANN and the Regional
    Internet Registries [ASOMOU] and documented in [ICANNv4],
    [ICANNv6], and [ICANNASN].
 Regional IRs
    In order to promote distribution of the Internet number resource
    registration function, RFC 1366 proposed delegating responsibility
    to regional bodies.  (Note: RFC 1366 was replaced by RFC 1466,
    which was replaced by RFC 2050.)  These bodies became known as the
    Regional Internet Registries (RIRs).  The RIRs operate in
    continent-sized geopolitical regions.  Currently, there are five
    RIRs: AfriNIC serving Africa, APNIC serving parts of Asia and the
    Pacific region, ARIN serving North America and parts of the
    Caribbean, LACNIC serving Latin America and parts of the
    Caribbean, and RIPE NCC serving Europe, parts of Asia and the
    Middle East.  The RIRs were established in a bottom-up fashion via
    a global policy process that has been documented as the ICANN
    "Internet Consensus Policy 2" [ICP-2], which details the
    principles and criteria for establishment of Regional Internet
    Registries.  The RIRs also conduct regional number policy
    development used in the administration of the number resources for
    which they are responsible.

Housley, et al. Informational [Page 4] RFC 7020 Internet Registry System August 2013

 Local IRs
    Local Internet Registries (LIRs) are established through a
    relationship with the body from which they received their
    addresses, typically the RIR that serves the region in which they
    operate, a parent LIR, or other number-allocating entity.  In
    cases where LIRs span multiple regions, those LIRs have
    established relationships with multiple RIRs.  LIRs perform IP
    address allocation services for their customers, typically ISPs,
    end users, or child LIRs (also known as "sub-LIRs").

4. Internet Numbers Registry Technical Considerations

 As a result of the system of technical standards and guidelines
 established by the IETF as well as historical and operational
 constraints, there have been technical considerations regarding the
 services provided by the Internet Numbers Registry System as it
 evolved.  These technical considerations have included:
 1)  Reverse DNS: In situations where reverse DNS was used, the
     policies and practices of the Internet Numbers Registry System
     have included consideration of the technical and operational
     requirements posed by reverse DNS zone delegation [RFC5855].
 2)  Public WHOIS: The policies and practices of the Internet Numbers
     Registry System have included consideration of the technical and
     operational requirements for supporting WHOIS services [RFC3013]
     [RFC3912].
 As the Internet and the Internet Numbers Registry System continue to
 evolve, it may be necessary for the Internet community to examine
 these and related technical and operational considerations and how
 best to meet them.  This evolution is discussed in the next section.

5. Internet Numbers Registry Evolution

 Over the years, the Internet Numbers Registry System has developed
 mechanisms by which the structures, policies, and processes of the
 Internet Numbers Registry System itself can evolve to meet the
 changing demands of the global Internet community.  Further evolution
 of the Internet Numbers Registry System is expected to occur in an
 open, transparent, and broad multi-stakeholder manner.
 Per the delineation of responsibility for Internet address policy
 issues specified in the IETF/IAB/ICANN MOU [RFC2860], discussions
 regarding the evolution of the Internet Numbers Registry System
 structure, policy, and processes are to take place within the ICANN
 framework and will respect ICANN's core values [ICANNBL].  These core

Housley, et al. Informational [Page 5] RFC 7020 Internet Registry System August 2013

 values encourage broad, informed participation reflecting the
 functional, geographic, and cultural diversity of the Internet at all
 levels of policy development and decision making, as well as the
 delegation of coordination functions and recognition of the policy
 roles of other responsible entities that reflect the interests of
 affected parties.  The discussions regarding Internet Numbers
 Registry evolution must also continue to consider the overall
 Internet address architecture and technical goals referenced in this
 document.
 The foregoing does not alter the IETF's continued responsibility for
 the non-policy aspects of Internet addressing such as the
 architectural definition of IP address and AS number spaces and
 specification of associated technical goals and constraints in their
 application, assignment of specialized address blocks, and
 experimental technical assignments as documented in RFC 2860.  In
 addition, in the cases where the IETF sets technical recommendations
 for protocols, practices, or services that are directly related to IP
 address space or AS numbers, such recommendations must be taken into
 consideration in Internet Numbers Registry System policy discussions
 regardless of venue.

6. Summary of Changes since RFC 2050

 Since RFC 2050 was published, the Internet and the Internet Numbers
 Registry System have undergone significant change.  This document
 describes the Internet Numbers Registry System as it presently exists
 and omits policy and operational procedures that have been superseded
 by ICANN and RIR policy since the publication of RFC 2050.
 One particular change of note is that RFC 2050 defined an appeal
 process and included:
    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.
 The RIRs have developed consensus-based policies for appeals, and
 over time, they have become accepted by the respective RIR
 communities.  As a result, the ability to further appeal to IANA is
 no longer appropriate.

7. Security Considerations

 It is generally recognized that accuracy and public availability of
 Internet registry data is often an essential component in researching
 and resolving security and operational issues on the Internet.

Housley, et al. Informational [Page 6] RFC 7020 Internet Registry System August 2013

8. Acknowledgements

 Several people have made comments on draft versions of this document.
 The authors would like to thank Randy Bush, Brian Carpenter, Daniel
 Karrenberg, Olaf Kolkman, Scott Bradner, Leslie Daigle, Adiel
 Akplogan, Mark Kosters, Elise Gerich, and SM for their constructive
 feedback and comments.  Additionally, we are indebted to the authors
 of RFC 1466 and RFC 2050 for their earlier contributions in this
 area.

9. References

9.1. Normative References

 [ASOMOU]   Published by ICANN, "ICANN Address Supporting Organization
            (ASO) MoU", October 2004,
            <http://archive.icann.org/en/aso/aso-mou-29oct04.htm>.
 [ICANNASN] Ratified by ICANN, "Internet Assigned Numbers Authority
            (IANA) Policy for Allocation of ASN Blocks to Regional
            Internet Registries", September 2010,
            <http://www.icann.org/en/resources/policy/global-
            addressing/global-policy-asn-blocks-21sep10-en.htm>.
 [ICANNBL]  ICANN, "Bylaws for Internet Corporation for Assigned Names
            and Numbers", December 2012,
            <http://www.icann.org/en/about/governance/bylaws>.
 [ICANNv4]  Ratified by ICANN, "Global Policy for Post Exhaustion IPv4
            Allocation Mechanisms by the IANA", May 2012,
            <http://www.icann.org/en/resources/policy/
            global-addressing/allocation-ipv4-post-exhaustion>.
 [ICANNv6]  Ratified by ICANN, "Internet Assigned Numbers Authority
            (IANA) Policy For Allocation of IPv6 Blocks to Regional
            Internet Registries", September 2006,
            <http://www.icann.org/en/resources/policy/
            global-addressing/allocation-ipv6-rirs>.
 [ICP-2]    ICANN, "ICP-2: Criteria for Establishment of New Regional
            Internet Registries", July 2001,
            <http://www.icann.org/icp/icp-2.htm>.
 [RFC2860]  Carpenter, B., Baker, F., and M. Roberts, "Memorandum of
            Understanding Concerning the Technical Work of the
            Internet Assigned Numbers Authority", RFC 2860, June 2000.

Housley, et al. Informational [Page 7] RFC 7020 Internet Registry System August 2013

 [RFC3013]  Killalea, T., "Recommended Internet Service Provider
            Security Services and Procedures", BCP 46, RFC 3013,
            November 2000.

9.2. Informative References

 [RFC3912]  Daigle, L., "WHOIS Protocol Specification", RFC 3912,
             September 2004.
 [RFC5855]  Abley, J. and T. Manderson, "Nameservers for IPv4 and IPv6
             Reverse Zones", BCP 155, RFC 5855, May 2010.

Housley, et al. Informational [Page 8] RFC 7020 Internet Registry System August 2013

Authors' Addresses

 Russ Housley
 Vigil Security, LLC
 918 Spring Knoll Drive
 Herndon, VA  20170
 USA
 Phone: +1 703 435 1775
 EMail: housley@vigilsec.com
 John Curran
 American Registry for Internet Numbers (ARIN)
 3635 Concorde Parkway
 Chantilly, VA  20151-1125
 USA
 Phone: +1 703 227 9845
 EMail: jcurran@arin.net
 Geoff Huston
 Asia Pacific Network Information Centre (APNIC)
 6 Cordelia St
 South Brisbane, QLD  4101
 Australia
 Phone: +61 7 3858 3100
 EMail: gih@apnic.net
 David Conrad
 Virtualized, LLC
 2310 Homestead Road, C1#204
 Los Altos, CA  94024
 USA
 Phone: +1 650 397 6102
 EMail: drc@virtualized.org

Housley, et al. Informational [Page 9]

/data/webs/external/dokuwiki/data/pages/rfc/rfc7020.txt · Last modified: 2013/08/24 00:01 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki