Internet Engineering Task Force (IETF) Category: Informational. APNIC D. Conrad Virtualized, LLC August 2013

Similar documents
Internet Structure and Organization

Internet Bodies.

GAO Engagement on the Internet Domain Name System Discussion Guide

Internet Operations and the RIRs

How To Transition To Annia.Org From Aaa To Anora.Org

Introduction to IP Numbers vs. Domain names. Adiel A. Akplogan CEO, AFRINIC. 2014

The IANA Functions. An Introduction to the Internet Assigned Numbers Authority (IANA) Functions

Internet Engineering Task Force (IETF) Category: Best Current Practice ISSN: February 2012

The Internet. On October 24, 1995, the FNC unanimously passed a resolution defining the term Internet.

The Internet Introductory material.

ICANN- INTERNET CORPORATION OF ASSIGNED NAMES & NUMBERS

IPv6 Address Planning

SSAC Report on the IANA Functions Contract

Regional Internet Registries. Statistics & Activities. Prepared By APNIC, ARIN, LACNIC, RIPE NCC

The Regional Internet Registries

Internet Technical Governance: Orange s view

Internet Engineering Task Force (IETF) Category: Best Current Practice ISSN: Facebook, Inc. S. Sheppard ATT Labs June 2011

Introduction to The Internet

Internet Engineering Task Force (IETF) Request for Comments: Category: Standards Track February 2013 ISSN:

APNIC Trial of Certification of IP Addresses and ASes

Introduction to The Internet. ISP/IXP Workshops

Topic 1: Internet Architecture & Addressing

Service Level Agreement for the IANA Numbering Services

Using Resource Certificates Progress Report on the Trial of Resource Certification

Draft WGIG Issue Paper on the Administration of Internet Names and IP Addresses

Service Level Agreement for the IANA Numbering Services

Ref: A. Leon Garcia and I. Widjaja, Communication Networks, 2 nd Ed. McGraw Hill, 2006 Latest update of this lecture was on

IPv6 Addressing. ISP Training Workshops

Internet Engineering Task Force (IETF) Category: Best Current Practice. C. Liljenstolpe Telstra Corp. M. Azinger Frontier Communications April 2012

RIPE Network Coordination Centre RIPE NCC LIR Tutorial

How To Write An Agreement Between The Nro And Icann

How To Get An Ipv6 Allocation On Ipv4 (Ipv4) From Ipv5) From The Ipvripe Ncc (Ip6) From A Ipvv6 Ipv2 (Ip4) To Ip

IPv6 and IPv4 Update from the RIPE NCC. Sandra Brás, Ferenc Csorba

Law Enforcement and Internet Governance: An Ounce of Prevention Is Worth a Pound of Cure

Internet Engineering Task Force (IETF) Category: Informational June 2010 ISSN:

INTERNET ORGANIZATION OVERVIEW OF THE INTERNET'S ORGANIZATION AND MAIN STANDARD BODIES. Internet Organization. Peter R. Egli INDIGOO.COM. indigoo.

What is AfriNIC, IPv4 exhaustion & IPv6 transition

IPv6Program. Expanding the Internet. The IPv4 to IPv6 transition

IPv6 in Africa. Adiel A. Akplogan. CEO, AfriNIC IICA Workshop. 22, September 2011

Current Counter-measures and Responses by the Domain Name System Community

An introduction to IANA Presentation Notes

Network Working Group Request for Comments: 1366 October 1992

Internet Engineering Task Force (IETF) Request for Comments: 6422 Updates: 3315 Category: Standards Track ISSN: December 2011

:0db8:2004:f000:20d:60ff: Continuing cooperation The NRO and Internet Governance. The. Number

technical Operations Area IP Resource Management

Internet Engineering Task Force (IETF) Juniper Networks January 2014

Policy Implementation and Experience Report. Leslie Nobile

How To Understand The Role Of Internet Governance

Testimony of. Hearing Entitled Should the Department of Commerce Relinquish Direct Oversight Over ICANN? April 10, 2014

IPv6 The Big Picture. Rob Evans, Janet

A PKI For IDR Public Key Infrastructure and Number Resource Certification

BGP. 1. Internet Routing

What's inside the cloud?!

Internet Protocol version 4 Part I

Comments to WGIG on Draft Working Papers Identifying Issues for Internet Governance. Submitted by APNIC

Domain Names and their Role for the Net

TECHNICAL REPORT Network Technologies (NTECH); Description of the DNS protocol usage in IP based operators networks

THE AMERICAN REGISTRY FOR INTERNET NUMBERS (ARIN)

Study Report on the IPv4 Address Space Exhaustion Issue (Phase I)

Understanding Internet Focus Institutions [Session 6]

Measuring IPv6 Deployment. Geoff Huston APNIC December 2009

APNIC elearning: Requesting IP Address

2015 IANA Functions Customer Service Survey Results

Creating an Enabling Environment for IPv6 Adoption

Network Working Group Request for Comments: 1591 Category: Informational March Domain Name System Structure and Delegation. Status of this Memo

256 4 = 4,294,967,296 ten billion = 18,446,744,073,709,551,616 ten quintillion. IP Addressing. IPv4 Address Classes

Internet Engineering Task Force (IETF) Request for Comments: Category: Standards Track ISSN: March 2011

The Internet Ecosystem

Hurricane Electric is using this document to update its customers and anyone else interested in Hurricane Electric s network offerings.

Request for Proposals for consulting services: Independent review of the ICANN Address Supporting Organization (ASO)

IPv6 Around the World

] RIN 0660 XA23:

4.1.2., , [Section Number Retired] Determination of IP address allocation

How to use the UNIX commands for incident handling. June 12, 2013 Koichiro (Sparky) Komiyama Sam Sasaki JPCERT Coordination Center, Japan

IRINN Open Policy Meeting

2014 IANA FUNCTIONS CUSTOMER SERVICE SURVEY RESULTS. Survey by Ebiquity Report by Leo Vegoda & Marilia Hirano

RIPE NCC Activity Plan 2005

2013 IANA Functions Customer Service Survey Results

IPE Database Features

Multi-Stakeholder Model Internet Governance

RPKI Tutorial. Certification. Goals. Current Practices in Filtering

Telecom and Internet Regulatory Challenges and Opportunities Names, Numbers, Internet Governance

Current Counter-measures and Responses by the Domain Name System Community

How It Works: 101: Naming, Addressing, Routing ALAIN DURAND ICANN

3. Flexible Contents Delivery System with Dynamic Server Deployment. 2. Related Works. 3.1 Server Proliferation 2.1 CDN

APNIC Internet Resource Management (IRM) Tutorial. Petaling Jaya, Malaysia 24 February 2014

Category: Standards Track Cisco Systems, Inc. March 1999

SSAC Advisory on the Changing Nature of IPv4 Address Semantics

Database Update. Johan Åhlén Assistant Manager and Denis Walker Business Analyst

Approaches of Managing IPv4 Exhaustion. We re running out of IPv4 addresses and we still have a lot of use for them even with the

Internet Engineering Task Force (IETF) Category: Standards Track. T. Reddy Cisco March 2015

APPENDIX A STANDARDS AND STANDARDS-SETTING ORGANIZATIONS. A.1 The Importance of Standards

Internet Engineering Task Force (IETF) Category: Informational. February 2013

RIPE Policy Development Process

INTERNET MANAGEMENT. Structured Evaluation Could Help Assess Proposed Transition of Key Domain Name and Other Technical Functions

Service Expectations of Root Servers

Baseline requirements Version 1.0 Errata

The Internet Domain Name System Explained for Non- Experts

RIPE 48, May 2004 NRO / ICANN MoU Amsterdam

Transcription:

Internet Engineering Task Force (IETF) Request for Comments: 7020 Obsoletes: 2050 Category: Informational ISSN: 2070-1721 R. Housley Vigil Security J. Curran ARIN 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]

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]

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]

IETF IANA 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. 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]

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]

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]

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/globaladdressing/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]

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

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]