idnits 2.17.1 draft-ietf-grow-no-more-unallocated-slash8s-01.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 : ---------------------------------------------------------------------------- == There are 4 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 1 instance of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 == There are 3 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 13, 2011) is 4725 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Informational RFC: RFC 1208 ** Downref: Normative reference to an Informational RFC: RFC 2544 ** Downref: Normative reference to an Informational RFC: RFC 3871 ** Obsolete normative reference: RFC 5735 (Obsoleted by RFC 6890) ** Downref: Normative reference to an Informational RFC: RFC 5737 Summary: 5 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group L. Vegoda 3 Internet-Draft ICANN 4 Intended status: BCP May 13, 2011 5 Expires: November 14, 2011 7 Time to Remove Filters for Previously Unallocated IPv4 /8s 8 draft-ietf-grow-no-more-unallocated-slash8s-01 10 Abstract 12 It has been common for network administrators to filter IP traffic 13 from and BGP prefixes of unallocated IPv4 address space. Now that 14 there are no longer any unallocated IPv4 /8s, this practise is more 15 complicated, fragile and expensive. Network administrators are 16 advised to remove filters based on the registration status of the 17 address space. 19 This document explains why any remaining packet and BGP prefix 20 filters for unallocated IPv4 /8s should now be removed on border 21 routers and documents those IPv4 unicast prefixes that should not be 22 routed across the public Internet. 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on November 14, 2011. 41 Copyright Notice 43 Copyright (c) 2011 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Traffic Filtering Options . . . . . . . . . . . . . . . . . . . 3 61 3.1. No Longer Filtering Based on Address Registration 62 Status . . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 3.2. Continuing to Filter Traffic from Unallocated IPv4 64 Space . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 4. Prefixes That Should Not be Routed Across the Internet . . . . 4 66 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 67 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 68 7. Normative References . . . . . . . . . . . . . . . . . . . . . 5 69 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 6 70 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 6 72 1. Introduction 74 It has been common for network administrators to filter IP traffic 75 from and BGP prefixes of unallocated IPv4 address space. Now that 76 there are no longer any unallocated IPv4 /8s, this practise is more 77 complicated, fragile and expensive. Network administrators are 78 advised to remove filters based on the registration status of the 79 address space. 81 This document explains why any remaining packet and BGP prefix 82 filters for unallocated IPv4 /8s should now be removed on border 83 routers and documents those IPv4 unicast prefixes that should not be 84 routed across the public Internet. 86 2. Terminology 88 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 89 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 90 document are to be interpreted as described in BCP 14, RFC 2119 91 [RFC2119]. 93 Bogons are packets sourced from addresses that have not yet been 94 allocated by IANA or the Regional Internet Registries (RIRs), or 95 addresses reserved for private or special use by RFCs [RFC3871]. 96 Martians are packets with an altogether bogus (non-registered or ill- 97 formed) Internet address [RFC1208]. Bogons are referred to as "Dark 98 IP" in some circles. 100 3. Traffic Filtering Options 102 3.1. No Longer Filtering Based on Address Registration Status 104 Network administrators who implemented filters for unallocated IPv4 105 /8s did so in the knowledge that those /8s were not a legitimate 106 source of traffic on the Internet and that there was a small number 107 of bogon filters to implement. Now that there are no longer any 108 unallocated unicast IPv4 /8s, there will be legitimate Internet 109 traffic coming from all unicast /8s that are not reserved for special 110 purposes in an RFC. 112 Removing packet and prefix filters based on the registration status 113 of the IPv4 address is a simple approach that will avoid blocking 114 legitimate Internet traffic. Network operators SHOULD remove both 115 ingress and egress packet filters as well as BGP prefix filters for 116 previously unallocated IPv4 /8s. 118 3.2. Continuing to Filter Traffic from Unallocated IPv4 Space 120 Some network administrators might want to continue filtering 121 unallocated IPv4 addresses managed by the RIRs. This requires 122 significantly more granular ingress filters and the highly dynamic 123 nature of the RIRs' address pools means that filters need to be 124 updated on a daily basis to avoid blocking legitimate incoming 125 traffic. 127 4. Prefixes That Should Not be Routed Across the Internet 129 Network operators who only wish to filter traffic originating from 130 addresses that should never be routed across the Internet, Martians, 131 can deploy a set of packet and prefix filters designed to block 132 traffic from address blocks reserved for special purposes. These 133 are: 135 - 0.0.0.0/8 (Local identification) [RFC1122]; 137 - 10.0.0.0/8 (Private use) [RFC1918]; 139 - 127.0.0.0/8 (Loopback) [RFC1122]; 141 - 169.254.0.0/16 (Link local) [RFC3927]; 143 - 172.16.0.0/12 (Private use) [RFC1918]; 145 - 192.0.2.0/24 (TEST-NET-1) [RFC5737]; 147 - 192.168.0.0/16 (Private use) [RFC1918]; 149 - 198.18.0.0/15 (Benchmark testing) [RFC2544]; 151 - 198.51.100.0/24 (TEST-NET-2) [RFC5737]; 153 - 203.0.113.0/24 (TEST-NET-3) [RFC5737]; 155 - 224.0.0.0/4 (Multicast) [RFC5771]; and 157 - 240.0.0.0/4 (Future use) [RFC1112]. 159 A full set of special use IPv4 addresses can be found in [RFC5735]. 160 It includes prefixes that are intended for Internet use. 162 5. Security Considerations 164 The cessation of filters based on unallocated IPv4 /8 allocations is 165 an evolutionary step towards reasonable security filters. While 166 these filters are no longer necessary, and in fact harmful, this does 167 not obviate the need to continue other security solutions. These 168 other solutions are as necessary today as they ever were. 170 6. IANA Considerations 172 This document makes no request of IANA. 174 7. Normative References 176 [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, 177 RFC 1112, August 1989. 179 [RFC1122] Braden, R., "Requirements for Internet Hosts - 180 Communication Layers", STD 3, RFC 1122, October 1989. 182 [RFC1208] Jacobsen, O. and D. Lynch, "Glossary of networking terms", 183 RFC 1208, March 1991. 185 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 186 E. Lear, "Address Allocation for Private Internets", 187 BCP 5, RFC 1918, February 1996. 189 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 190 Requirement Levels", BCP 14, RFC 2119, March 1997. 192 [RFC2544] Bradner, S. and J. McQuaid, "Benchmarking Methodology for 193 Network Interconnect Devices", RFC 2544, March 1999. 195 [RFC3871] Jones, G., "Operational Security Requirements for Large 196 Internet Service Provider (ISP) IP Network 197 Infrastructure", RFC 3871, September 2004. 199 [RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic 200 Configuration of IPv4 Link-Local Addresses", RFC 3927, 201 May 2005. 203 [RFC5735] Cotton, M. and L. Vegoda, "Special Use IPv4 Addresses", 204 BCP 153, RFC 5735, January 2010. 206 [RFC5737] Arkko, J., Cotton, M., and L. Vegoda, "IPv4 Address Blocks 207 Reserved for Documentation", RFC 5737, January 2010. 209 [RFC5771] Cotton, M., Vegoda, L., and D. Meyer, "IANA Guidelines for 210 IPv4 Multicast Address Assignments", BCP 51, RFC 5771, 211 March 2010. 213 Appendix A. Acknowledgments 215 Thanks are owed to Kim Davies, Terry Manderson, Dave Piscitello and 216 Joe Abley for helpful advice on how to focus this document. Thanks 217 also go to Andy Davidson, Philip Smith and Rob Thomas for early 218 reviews and suggestions for improvements to the text and Carlos 219 Pignataro for his support and comments. 221 Author's Address 223 Leo Vegoda 224 Internet Corporation for Assigned Names and Numbers 225 4676 Admiralty Way, Suite 330 226 Marina del Rey, CA 90292 227 United States of America 229 Phone: +1-310-823-9358 230 Email: leo.vegoda@icann.org 231 URI: http://www.iana.org/