idnits 2.17.1 draft-manderson-routing-intent-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 17, 2011) is 4636 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Obsolete informational reference (is this intentional?): RFC 2460 (Obsoleted by RFC 8200) -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 5736 (Obsoleted by RFC 6890) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group T. Manderson 3 Internet-Draft ICANN 4 Intended status: Standards Track August 17, 2011 5 Expires: February 18, 2012 7 Signaling Public Routing Intent (PRI) for Internet Protocol Addresses in 8 IANA Registries 9 draft-manderson-routing-intent-02.txt 11 Abstract 13 This document provides direction to IANA to mark existing and future 14 IANA IPv4 and IPv6 allocations with generic terms pertaining to the 15 Public (global) Routing Intent (PRI). 17 Status of this Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on February 18, 2012. 34 Copyright Notice 36 Copyright (c) 2011 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3 52 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 53 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5 54 4. Wording for future IETF Documents . . . . . . . . . . . . . . 6 55 5. Special Address Registries . . . . . . . . . . . . . . . . . . 7 56 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 57 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 58 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 59 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 60 9.1. Normative References . . . . . . . . . . . . . . . . . . . 11 61 9.2. Informative References . . . . . . . . . . . . . . . . . . 11 62 Appendix A. Example IPv4 Address Registry . . . . . . . . . . . . 12 63 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13 65 1. Requirements Notation 67 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 68 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 69 document are to be interpreted as described in [RFC2119]. 71 2. Introduction 73 The IANA address registries currently do not have a uniform and 74 consistent nomenclature to signal if an allocation is intended to be 75 publicly routed. While some registries, such as the IANA IPv4 76 Special Purpose Address Registry [RFC5736], include a column 77 describing routing scope it is the exception. The consequence of 78 this is that at present the intended routing posture of many 79 allocations is, at best, implied. 81 Work is underway in the IETF to design and document a number of 82 systems or architectures to facilitate the desire to secure the 83 Internet routing system. [I-D.ietf-sidr-arch] describes one such 84 architecture. Such work will require an explicit statement as to the 85 intended public routability of an allocation. Over time several 86 architectures may come to exist, and in support of the idea of 87 routing security, this document provides direction to IANA to mark 88 existing and future IANA IPv4 [RFC0791] and IPv6 [RFC2460] 89 allocations with generic terms pertaining to the Public (global) 90 Routing Intent (PRI) and with a granularity that removes any possible 91 ambiguity in interpreting the address registry. 93 These well defined generic terms can then be applied in technology 94 solutions that address routing security, or other routing concerns. 96 3. Definitions 98 Publically Routed: Where the announcement of a prefix contained 99 within, or representing, an allocation is exchanged between 2 or more 100 Autonomous Systems that do not share a common and unified routing 101 policy except for the announcement and acceptance of routes 102 containing a prefix directly allocated to themselves. 104 Routable: An IPv4 [RFC0791] or IPv6 [RFC2460] prefix that is intended 105 to be (publicly) routed. 107 Not Routable: An IPv4 [RFC0791] or IPv6 [RFC2460] prefix that is NOT 108 intended to be (publicly) routed. 110 4. Wording for future IETF Documents 112 All future IETF documents that request IANA [RFC5226] to allocate, 113 assign, or reserve an IPv4 [RFC0791] or IPv6 [RFC2460] address block 114 MUST include a statement for each and every unique prefix it requests 115 that describes the routing intent for the prefix. Suitable examples 116 are: 118 1) This prefix, 2001:DB8::/32, is to be considered Routable. 119 2) 2001:DB8::/32 is for private use and intended to be Not Routable. 120 3) The assignment of 2001:DB8::/32 is intended to be Routable. 122 5. Special Address Registries 124 The IANA IPv4 Special Purpose Address Registry [RFC5736] already 125 contains a routing scope definition. While this registry is the 126 exception for address registries, the PRI column MUST be added to the 127 IANA IPv4 Special Purpose Address Registry leaving the existing 128 Routing Scope in place for additional information to the reader. 130 6. IANA Considerations 132 This document directs IANA to extend all the IPv4 and IPv6 address 133 registries to record Public Routing Intent (PRI) as either "Routable" 134 or "Not Routable". This intent should be initially taken from the 135 appendices in [I-D.ietf-sidr-iana-objects] for reserved, special use, 136 and unallocated address space. Address space already allocated to 137 the Regional Internet Registries or other entities for use on the 138 public internet MUST be marked as "Routable". Future standards 139 action IETF documents that request action in all IANA IPv4 or IPv6 140 addresses registries MUST include a statement pertaining to the 141 routing intent of the resulting action as described in this document. 143 Implementation of this document further requires IANA to update the 144 IPv4 and IPv6 address registries to use a granularity commensurate 145 with the most specific entry in the address registry. An example 146 registry can be found in Appendix A (Appendix A). 148 7. Security Considerations 150 This document does not alter the security profile for IANA IPv4 151 [RFC0791] or IPv6 [RFC2460] address registries. 153 8. Acknowledgments 155 The Author appreciates the review, consideration, and helpful 156 feedback from Leo Vegoda, Michelle Cotton, Benson Schliesser, Arturo 157 Servin, and Geoff Huston. 159 9. References 161 9.1. Normative References 163 [I-D.ietf-sidr-iana-objects] 164 Manderson, T., Vegoda, L., and S. Kent, "RPKI Objects 165 issued by IANA", draft-ietf-sidr-iana-objects-03 (work in 166 progress), May 2011. 168 9.2. Informative References 170 [I-D.ietf-sidr-arch] 171 Lepinski, M. and S. Kent, "An Infrastructure to Support 172 Secure Internet Routing", draft-ietf-sidr-arch-13 (work in 173 progress), May 2011. 175 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 176 September 1981. 178 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 179 Requirement Levels", BCP 14, RFC 2119, March 1997. 181 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 182 (IPv6) Specification", RFC 2460, December 1998. 184 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 185 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 186 May 2008. 188 [RFC5736] Huston, G., Cotton, M., and L. Vegoda, "IANA IPv4 Special 189 Purpose Address Registry", RFC 5736, January 2010. 191 Appendix A. Example IPv4 Address Registry 193 This is a truncated example of how the resulting IANA IPv4 address 194 registry might appear. The existing IANA IPv4 address registry 195 columns of Designation, Date, and Whois have been removed from this 196 example for brevity reasons only. 198 | Prefix | ... | Status | PRI | Note | 199 | ... 200 | 198.0/12 | | ALLOCATED | Routable | | 201 | 198.16/15 | | ALLOCATED | Routable | | 202 | 198.18/15 | | RESERVED | Not Routable | [ref] | 203 | 198.20/14 | | ALLOCATED | Routable | | 204 | 198.24/13 | | ALLOCATED | Routable | | 205 | 198.32/12 | | ALLOCATED | Routable | | 206 | 198.48/15 | | ALLOCATED | Routable | | 207 | 198.50/16 | | ALLOCATED | Routable | | 208 | 198.51.0/18 | | ALLOCATED | Routable | | 209 | 198.51.64/19 | | ALLOCATED | Routable | | 210 | 198.51.96/22 | | ALLOCATED | Routable | | 211 | 198.51.100.0/24 | | RESERVED | Not Routable | [ref] | 212 | 198.51.101/24 | | ALLOCATED | Routable | | 213 | 198.51.102/23 | | ALLOCATED | Routable | | 214 | 198.51.104/21 | | ALLOCATED | Routable | | 215 | 198.51.112/20 | | ALLOCATED | Routable | | 216 | 198.51.128/17 | | ALLOCATED | Routable | | 217 | 198.52/14 | | ALLOCATED | Routable | | 218 | 198.56/13 | | ALLOCATED | Routable | | 219 | 198.64/10 | | ALLOCATED | Routable | | 220 | 198.128/9 | | ALLOCATED | Routable | | 221 | ... 223 Author's Address 225 Terry Manderson 226 ICANN 228 Email: terry.manderson@icann.org