<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [

    <!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
    <!ENTITY RFC2860 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2860.xml">
    <!ENTITY RFC1918 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1918.xml">
    <!ENTITY RFC5736 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5736.xml">
    <!ENTITY RFC4380 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4380.xml">
    <!ENTITY RFC5180 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5180.xml">
    <!ENTITY RFC5735 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5735.xml">
    <!ENTITY RFC3068 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3068.xml">
    <!ENTITY RFC4271 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4271.xml">
    <!ENTITY RFC3779 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3779.xml">
    <!ENTITY RFC5771 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5771.xml">
    <!ENTITY RFC4291 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4291.xml">
    <!ENTITY I-D.ietf-sidr-arch SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-sidr-arch.xml">
    <!ENTITY I-D.ietf-sidr-res-certs SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-sidr-res-certs.xml">
    <!ENTITY I-D.ietf-sidr-signed-object SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-sidr-signed-object.xml">
    <!ENTITY I-D.ietf-sidr-roa-format SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-sidr-roa-format.xml">
    <!ENTITY I-D.ietf-sidr-ghostbusters SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-sidr-ghostbusters.xml"> 
    <!ENTITY I-D.ietf-sidr-rpki-manifests SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-sidr-rpki-manifests.xml">
    <!ENTITY I-D.ietf-sidr-ltamgmt SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-sidr-ltamgmt.xml">
    <!ENTITY I-D.ietf-sidr-roa-validation SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-sidr-roa-validation.xml">
    <!ENTITY I-D.ietf-sidr-usecases SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-sidr-usecases.xml">
    <!ENTITY I-D.ietf-sidr-cp SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-sidr-cp.xml">
    <!ENTITY I-D.ietf-sidr-rpki-manifests SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-sidr-rpki-manifests.xml">
    
]>


<rfc category="bcp" ipr='trust200902' docName='draft-ietf-sidr-iana-objects-00.txt'>

<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>

<front>
	
    <title abbrev='IANA RPKI Objects'>RPKI Objects issued by IANA</title>

    <author initials="T" surname="Manderson" fullname="Terry Manderson">
	 	<organization abbrev="">ICANN</organization>
		<address><email>terry.manderson@icann.org</email></address>
    </author>
    
    <author initials="L" surname="Vegoda" fullname="Leo Vegoda">
	 	<organization abbrev="">ICANN</organization>
		<address><email>leo.vegoda@icann.org</email></address>
    </author>
    
    <author initials="S" surname="Kent" fullname="Steve Kent">
	 	<organization abbrev="">BBN</organization>
		<address><email>kent@bbn.com</email></address>
    </author>
    
	
    
    <date year="2011" month="February" />
    <area>Routing</area>
    <abstract>
    <t>This document provides specific direction to IANA as to the RPKI objects it should issue.
	</t>
    </abstract>
</front>



<middle>

<section title="Requirements Notation">
  <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
  "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
  and "OPTIONAL" in this document are to be interpreted as
  described in <xref target="RFC2119"/>.</t>
</section>

<section anchor="Intro" title="Introduction">

<t><xref target="I-D.ietf-sidr-arch">An Infrastructure to Support Secure Internet Routing</xref> directs 
IANA <xref target="RFC2860"></xref> to issue RPKI objects for which it is authoritative. 
This document describes the objects IANA will issue.</t>


<t>The signed objects described here that IANA will issue are the unallocated, reserved, special use IPv4 
and IPv6 address blocks, and reserved Autonomous System numbers. These number resources are managed by IANA 
for the IETF, and thus IANA bears the responsibility of issuing the 
corresponding RPKI objects. The reader is encouraged to consider the technical effects on the public 
routing system of the signed object issuance proposed for IANA in this document.</t>

<t>This document does not deal with localized <xref target="RFC4271">BGP</xref> routing 
systems as those are under the policy controls of the 
organizations that operate them. Readers are directed to <xref target="I-D.ietf-sidr-ltamgmt">Local Trust Anchor Management for the Resource Public Key Infrastructure</xref>
for a description od how to locally override IANA issued objects, e.g. to enable use of 
unallocated, reserved, and special use IPv4 
and IPv6 address blocks in a local context.
</t>

<t>The direction to IANA contained herein follows the ideal that it should represent the perfect technical
behavior in registry, and related registry, actions.</t>

</section>

<section anchor="reading" title="Suggested Reading">

<t>
Readers should be familiar with the RPKI, the RPKI Repository
   Structure, and the various RPKI objects, uses and interpretations described in the following:
  <xref target="I-D.ietf-sidr-arch"></xref>,
  <xref target="I-D.ietf-sidr-res-certs"></xref>,
  <xref target="I-D.ietf-sidr-roa-format"></xref>,
  <xref target="I-D.ietf-sidr-ghostbusters"></xref>,
  <xref target="I-D.ietf-sidr-ltamgmt"></xref>,
  <xref target="I-D.ietf-sidr-roa-validation"></xref>,
  <xref target="I-D.ietf-sidr-usecases"></xref>,
  <xref target="I-D.ietf-sidr-cp"></xref>,
  <xref target="I-D.ietf-sidr-rpki-manifests"></xref>.
</t>

</section>

<section title="Definitions">

<t>Internet Number Resources (INR): The number identifiers for IPv4 and IPv6 addresses, and for Autonomous Systems.</t>
<t>IANA: Internet Assigned Numbers Authority (a traditional name, used
   here to refer to the technical team making and publishing the
   assignments of Internet protocol technical parameters). The technical team of IANA
   is currently a part of ICANN <xref target="RFC2860"/>.</t>

<t>RPKI: Resource Public Key Infrastructure. A Public Key Infrastructure designed to provide a secure 
	basis for assertions about holdings of Internet numeric resources. Certificates issued under the 
	RPKI contain additional attributes that identify IPv4, IPv6, and Autonomous System Number (ASN) resources.
</t>
	
<t>ROA: Route Origination Authorization. A ROA is an RPKI object that enables the holder of the address prefix to specify an AS that 
	is permitted to originate (in BGP) routes for that prefix.</t>

<t>AS0 ROA: <xref target="I-D.ietf-sidr-roa-validation">Validation of Route Origination using the Resource Certificate PKI and ROAs</xref> states "A ROA with a subject of AS0 (AS0-ROA) is an attestation by the holder 
	of a prefix that the prefix described in the ROA, and any more specific prefix, 
	should not be used in a routing context."</t>
	
<t>“Not intended to be (publicly) routed”: This phrase refers to prefixes that are not meant 
	to be represented in the global Internet routing table (for example 192.168/16, <xref target="RFC1918"></xref>).</t>


</section>



<section title="Reserved Resources">
<t>Reserved IPv4 and IPv6 resources are held back for various reasons by IETF action. 
	Generally such resources are not intended to be globally routed. An example of such a 
	reservation is 127.0.0.0/8 <xref target="RFC5735"></xref></t>

<t>IANA should issue an AS0 ROA for all reserved IPv4 and 
	IPv6 resources not intended to be routed</t>
	
<t>There are a small number of reserved resources which are intended to be routed, for example 192.88.99.0/24 <xref target="RFC3068"></xref></t>

<t>IANA MUST refrain from issuing any ROAs (AS0 or otherwise) for reserved resources that are expected to be 
		globally routed.</t>

</section>

<section title="Unallocated Resources">
<t>Internet Number Resources that have not yet been allocated for 
	special purposes <xref target="RFC5736"></xref>, to Regional
	Internet Registries (RIRs), or to others are considered as not intended to 
	be globally routed.</t>
   
   <t>IANA MUST issue an AS0 ROA for all Unallocated Resources.
</t>	
</section>

<section title="Special Purpose Registry Resources">
	<t>Special Registry Resources <xref target="RFC5736"></xref> fall into one of two categories in terms of routing. Either 
		the resource is intended to be seen in the global Internet 
		routing table in some fashion, or it isn't. An example of a special purpose registry INR 
		that is intended for global routing is 2001:0000::/32 <xref target="RFC4380"></xref>. 
		An example of an INR not intended to be seen would be 2001:002::/48 <xref target="RFC5180"></xref></t>
	<t>IANA MUST refrain from issuing any ROAs (AS0 or otherwise) for Special Purpose Registry Resources that are intended to be 
		globally routed.</t>
	<t>IANA MUST issue an AS0 ROA for Special Purpose Registry Resources that are not intended to be globally routed.</t>
</section>

<section title="Multicast">
	<t>Within the IPv4 Multicast <xref target="RFC5771"></xref> and IPv6 Multicast <xref target="RFC4291"></xref> registries 
	there are a number of Multicast registrations that are not intended to be globally routed.</t>
	<t>IANA MUST issue an AS0 ROA covering the following IPv4 and IPv6 multicast INRs:</t>
	
		<figure><artwork>
<![CDATA[
IPv4:
	- Local Network Control Block 
	   224.0.0.0 - 224.0.0.255 (224.0.0/24)
	- IANA Reserved portions of RESERVED 
	   224.1.0.0-224.1.255.255 (224.1/16)
	- RESERVED 
	   224.5.0.0-224.251.255.255 (251 /16s)
	   225.0.0.0-231.255.255.255 (7 /8s)
				
IPv6:
	- Node-Local Scope Multicast Addresses
	- Link-Local Scope Multicast Addresses
]]></artwork></figure>
				
	<t>IANA MUST refrain from issuing any ROAs (AS0 or otherwise) for any other multicast addresses unless directed.</t>
	
</section>


<section title="Informational Objects">
<t>One informational object that can exist at a publication point of an RPKI repository is 
	the <xref target="I-D.ietf-sidr-ghostbusters">Ghostbusters Record</xref>.</t>
<t>IANA MUST issue a ghostbusters object appropriate in content for the resources IANA maintains.</t>

	
</section>

<section title="Certificates and CRLs">
<t>Before IANA can issue a ROA it MUST first establish a RPKI Certificate Authority (CA) that covers unallocated, 
	reserved, and special use INRs by containing
	 <xref target="RFC3779">RFC 3379 extensions</xref> for those corresponding number resources in the CA Certificate.
	This CA MUST issue single use End Entity (EE) certificates for each ROA. The EE certificate will conform to the
	 <xref target="I-D.ietf-sidr-res-certs">Resource Certificate Profile</xref> and the additional constraints specified in 
	 <xref target="I-D.ietf-sidr-roa-format"></xref>. IANA MUST maintain a publication point for this CA's use and publish <xref target="I-D.ietf-sidr-rpki-manifests">manifests</xref> (with its corresponding EE 
	certificate). A Certificate Revocation List (CRL) will be issued under this CA certificate. All objects issued by this CA will 
	conform to a published <xref target="I-D.ietf-sidr-cp">Certificate Policy</xref>.
	</t>

</section>

<section title="IANA Considerations">

<t>This document directs IANA to issue, or refrain from issuing, the specific objects described 
	here for the current set of reserved, unallocated, and special registry Internet Number Resources. 
	Further it MUST notify all other INR registries that RPKI objects have been issued for specific Internet Number Resources
	to avoid duplicates being issued thus reducing the burden on any relying party.</t>
</section>

<section title="Security Considerations">
<t>This document does not alter the security profile of the RPKI from that already discussed in SIDR-WG documents.
</t>

</section>

<section title="Acknowledgements">
<t>The authors acknowledge Dave Meyer 
	for helpful direction with regard to multicast assignments.</t>
</section>


</middle>



<back>
  
  <references title="Normative References">
  	
 	&RFC2119;
 	&RFC2860;
 	&RFC1918;
 	&RFC5736;
 	&RFC4380;
 	&RFC5180;
 	&RFC5735;
 	&RFC3068;
 	&RFC4271;
 	&RFC3779;
 	&RFC4291;
 	&RFC5771;
 	
 	&I-D.ietf-sidr-arch;
 	&I-D.ietf-sidr-roa-format;
 	&I-D.ietf-sidr-ghostbusters;
 	&I-D.ietf-sidr-ltamgmt;
 	&I-D.ietf-sidr-roa-validation;
 	&I-D.ietf-sidr-usecases;
 	&I-D.ietf-sidr-cp;
 	&I-D.ietf-sidr-rpki-manifests;
 	&I-D.ietf-sidr-res-certs;
 	
  </references>
  
</back>
</rfc>
