idnits 2.17.1 draft-ietf-grow-no-more-unallocated-slash8s-04.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 (October 12, 2011) is 4577 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) ** Obsolete normative reference: RFC 5735 (Obsoleted by RFC 6890) Summary: 1 error (**), 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 October 12, 2011 5 Expires: April 14, 2012 7 Time to Remove Filters for Previously Unallocated IPv4 /8s 8 draft-ietf-grow-no-more-unallocated-slash8s-04 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 April 14, 2012. 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. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 69 7.1. Normative References . . . . . . . . . . . . . . . . . . . 5 70 7.2. Informative References . . . . . . . . . . . . . . . . . . 5 71 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 6 72 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 6 74 1. Introduction 76 It has been common for network administrators to filter IP traffic 77 from and BGP prefixes of unallocated IPv4 address space. Now that 78 there are no longer any unallocated IPv4 /8s, this practise is more 79 complicated, fragile and expensive. Network administrators are 80 advised to remove filters based on the registration status of the 81 address space. 83 This document explains why any remaining packet and BGP prefix 84 filters for unallocated IPv4 /8s should now be removed on border 85 routers and documents those IPv4 unicast prefixes that should not be 86 routed across the public Internet. 88 2. Terminology 90 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 91 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 92 document are to be interpreted as described in BCP 14, RFC 2119 93 [RFC2119]. 95 Martians [RFC1208] is a humorous term applied to packets that turn up 96 unexpectedly on the wrong network because of bogus routing entries. 97 It is also used as a name for a packet which has an altogether bogus 98 (non-registered or ill-formed) Internet address. Bogons [RFC3871] 99 are packets sourced from addresses that have not yet been allocated 100 by IANA or the Regional Internet Registries (RIRs), or addresses 101 reserved for private or special use by RFCs [RFC5735].Bogons are 102 referred to as "Dark IP" in some circles. . 104 3. Traffic Filtering Options 106 3.1. No Longer Filtering Based on Address Registration Status 108 Network administrators who implemented filters for unallocated IPv4 109 /8s did so in the knowledge that those /8s were not a legitimate 110 source of traffic on the Internet and that there was a small number 111 of bogon filters to implement. Now that there are no longer any 112 unallocated unicast IPv4 /8s, there will be legitimate Internet 113 traffic coming from all unicast /8s that are not reserved for special 114 purposes in an RFC. 116 Removing packet and prefix filters based on the registration status 117 of the IPv4 address is a simple approach that will avoid blocking 118 legitimate Internet traffic. Network operators SHOULD remove both 119 ingress and egress packet filters as well as BGP prefix filters for 120 previously unallocated IPv4 /8s. 122 3.2. Continuing to Filter Traffic from Unallocated IPv4 Space 124 Some network administrators might want to continue filtering 125 unallocated IPv4 addresses managed by the RIRs. This requires 126 significantly more granular ingress filters and the highly dynamic 127 nature of the RIRs' address pools means that filters need to be 128 updated on a daily basis to avoid blocking legitimate incoming 129 traffic. 131 4. Prefixes That Should Not be Routed Across the Internet 133 Network operators who only wish to filter traffic originating from 134 addresses that should never be routed across the Internet, Martians, 135 can deploy a set of packet and prefix filters designed to block 136 traffic from address blocks reserved for special purposes. These 137 are: 139 - 0.0.0.0/8 (Local identification) [RFC1122]; 141 - 10.0.0.0/8 (Private use) [RFC1918]; 143 - 127.0.0.0/8 (Loopback) [RFC1122]; 145 - 169.254.0.0/16 (Link local) [RFC3927]; 147 - 172.16.0.0/12 (Private use) [RFC1918]; 149 - 192.0.2.0/24 (TEST-NET-1) [RFC5737]; 151 - 192.168.0.0/16 (Private use) [RFC1918]; 153 - 198.18.0.0/15 (Benchmark testing) [RFC2544]; 155 - 198.51.100.0/24 (TEST-NET-2) [RFC5737]; 157 - 203.0.113.0/24 (TEST-NET-3) [RFC5737]; 159 - 224.0.0.0/4 (Multicast) [RFC5771]; and 161 - 240.0.0.0/4 (Future use) [RFC1112]. 163 A full set of special use IPv4 addresses can be found in [RFC5735]. 164 It includes prefixes that are intended for Internet use. 166 5. Security Considerations 168 The cessation of filters based on unallocated IPv4 /8 allocations is 169 an evolutionary step towards reasonable security filters. While 170 these filters are no longer necessary, and in fact harmful, this does 171 not obviate the need to continue other security solutions. These 172 other solutions are as necessary today as they ever were. 174 6. IANA Considerations 176 This document makes no request of IANA. 178 7. References 180 7.1. Normative References 182 [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, 183 RFC 1112, August 1989. 185 [RFC1122] Braden, R., "Requirements for Internet Hosts - 186 Communication Layers", STD 3, RFC 1122, October 1989. 188 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 189 E. Lear, "Address Allocation for Private Internets", 190 BCP 5, RFC 1918, February 1996. 192 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 193 Requirement Levels", BCP 14, RFC 2119, March 1997. 195 [RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic 196 Configuration of IPv4 Link-Local Addresses", RFC 3927, 197 May 2005. 199 [RFC5735] Cotton, M. and L. Vegoda, "Special Use IPv4 Addresses", 200 BCP 153, RFC 5735, January 2010. 202 [RFC5771] Cotton, M., Vegoda, L., and D. Meyer, "IANA Guidelines for 203 IPv4 Multicast Address Assignments", BCP 51, RFC 5771, 204 March 2010. 206 7.2. Informative References 208 [RFC1208] Jacobsen, O. and D. Lynch, "Glossary of networking terms", 209 RFC 1208, March 1991. 211 [RFC2544] Bradner, S. and J. McQuaid, "Benchmarking Methodology for 212 Network Interconnect Devices", RFC 2544, March 1999. 214 [RFC3871] Jones, G., "Operational Security Requirements for Large 215 Internet Service Provider (ISP) IP Network 216 Infrastructure", RFC 3871, September 2004. 218 [RFC5737] Arkko, J., Cotton, M., and L. Vegoda, "IPv4 Address Blocks 219 Reserved for Documentation", RFC 5737, January 2010. 221 Appendix A. Acknowledgments 223 Thanks are owed to Kim Davies, Terry Manderson, Dave Piscitello and 224 Joe Abley for helpful advice on how to focus this document. Thanks 225 also go to Andy Davidson, Philip Smith and Rob Thomas for early 226 reviews and suggestions for improvements to the text and Carlos 227 Pignataro for his support and comments. 229 Author's Address 231 Leo Vegoda 232 Internet Corporation for Assigned Names and Numbers 233 4676 Admiralty Way, Suite 330 234 Marina del Rey, CA 90292 235 United States of America 237 Phone: +1-310-823-9358 238 Email: leo.vegoda@icann.org 239 URI: http://www.iana.org/