idnits 2.17.1 draft-fuller-240space-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 197. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 208. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 215. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 221. 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 6 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. -- The draft header indicates that this document updates RFC3330, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year (Using the creation date from RFC3330, updated by this document, for RFC5378 checks: 2002-02-25) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 30, 2007) is 6056 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 normative reference: RFC 3330 (Obsoleted by RFC 5735) -- Obsolete informational reference (is this intentional?): RFC 2766 (Obsoleted by RFC 4966) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group V. Fuller 3 Internet-Draft E. Lear 4 Updates: 3330 (if approved) D. Meyer 5 Intended status: Standards Track Cisco Systems 6 Expires: March 2, 2008 August 30, 2007 8 Reclassifying 240/4 as usable unicast address space 9 draft-fuller-240space-00.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on March 2, 2008. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2007). 40 Abstract 42 This memo reclassifies the address block 240.0.0.0/4 as usable 43 address space. While the community has not concluded as to whether 44 the block should be considered public or private, it is clear given 45 the current consumption rate that the block should not be left 46 unused. This document also makes several recommendations on ways 47 that current implementations of the IP protocol stack will need to be 48 modified to make this address space usable. 50 1. Introduction 52 Recent estimates [1] indicate that the Internet Assigned Numbers 53 Authority (IANA) will exhaust the unallocated pool of 32-bit IPv4 54 addresses some time sometime between 2008 and 2010. As that time 55 rapidly approaches, the Internet community must consider what it 56 should do with address space currently reserved for future use. 57 [RFC3330] states that the address range 240.0.0.0/4 is reserved for 58 future use. There are several possible uses of this block. One 59 would be to reclassify the block as private address space, as defined 60 in [RFC1918], so that large private organizations that have outgrown 61 the other private blocks have additional room for network expansion. 62 Another possibility is for the address space to be made available for 63 public Internet use. A decision on which of these alternatives (if 64 either) is chosen requires additional analysis and debate; what is 65 clear, though, is that today's IP protocol stack implementations will 66 need to be modified to support any use of the currently-reserved 67 space as most today return errors when such addresses are used. 69 This memo requires implementors to make the changes necessary to 70 receive, transmit, and forward packets that contain addresses in this 71 block as if they were within any other unicast address block. 73 It is envisioned that utility of this block will grow over time. 74 Some devices may never be able to use it as their IP implementations 75 have no update mechanism. This is not to say that the block will 76 find no use. For example, home implementations that make use of 77 network address translation [RFC2766] can also make use of this range 78 as their public facing address once the resources people wish to 79 access have been updated. Similarly, organizations building new 80 networks, composed of equipment with new IP implementations that will 81 not need to interoperate with legacy equipment, may benefit from the 82 availability of this address space. 84 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 85 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 86 document are to be interpreted as described in [RFC2119]. 88 2. Implementation considerations 90 At the present time, most IP implementation consider any IP address 91 in the range 240.0.0.0 through 255.255.255.255 to be invalid as the 92 source or destination of a datagram. The check for such "illegal" 93 addresses may be made in many places, including at datagram receipt, 94 before IP datagram transmission, when an IP address is assigned to a 95 network interface, or even by router and firewall configuration 96 parsers. Because 240.0.0.0/4 is henceforth reclassified as usable 97 address space, implementations MUST treat this range as they would 98 any other unicast address range. Hence implementors should review 99 all of the above mentioned places and possibly others as they update 100 their implementations and remove those checks. 102 How the check is implemented may vary, but a common method is to 103 treat the IP address as a 32-bit quantity in network byte order, 104 performing a logical AND operation with the value hexidecimal 105 F0000000, and testing to see if the result is hexidecimal F0000000. 106 If the test succeeds, the address is rejected. 108 Note that the broadcast address, 255.255.255.255, still must be 109 treated specially in each case: it is illegal as a source IP address, 110 it is illegal as an network interface address, and it matches the 111 local system when used as the destination address in a received 112 datagram. 114 3. Security Considerations 116 The reclassification of 240.0.0.0/4 as a unicast block presents the 117 same security issues as any other unicast block, with the possible 118 addition that attackers may attempt to exploit poorly developed 119 security software that cannot handle the change. The authors have 120 not explored whether such implementations exist. 122 4. IANA Considerations 124 Although this memo requires implementations to treat addresses in the 125 range 240.0.0.0/4 the same as any other unicast addresses, it does 126 not change the "reserved" status of the 240.0.0.0/4 address block. 127 The IANA is requested to continue to reserve this block for future 128 use, with the understanding that future standards action will define 129 how it is to be allocated. 131 5. References 133 5.1. Normative References 135 [RFC3330] IANA, "Special-Use IPv4 Addresses", RFC 3330, 136 September 2002. 138 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 139 Requirement Levels", RFC 2119, March 1997. 141 5.2. Informative References 143 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., 144 and E. Lear, "Address Allocation for Private Internets", 145 RFC 1918, February 1996. 147 [RFC2766] Tsirtsis, G. and P. Srisuresh, "Network Address 148 Translation - Protocol Translation", RFC 2766, 149 February 2000. 151 URIs 153 [1] 155 Appendix A. Changes 157 Authors' Addresses 159 Vince Fuller 160 Cisco Systems 161 Tasman Drive 162 San Jose, CA 95134 163 USA 165 Email: vaf@cisco.com 167 Eliot Lear 168 Cisco Systems 169 Glatt-com, 2nd Floor 170 Glattzentrum, Zurich 8301 171 Switzerland 173 Email: lear@cisco.com 175 David Meyer 176 Cisco Systems 177 Tasman Drive 178 San Jose, CA 95134 179 USA 181 Email: dmm@cisco.com 183 Full Copyright Statement 185 Copyright (C) The IETF Trust (2007). 187 This document is subject to the rights, licenses and restrictions 188 contained in BCP 78, and except as set forth therein, the authors 189 retain all their rights. 191 This document and the information contained herein are provided on an 192 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 193 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 194 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 195 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 196 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 197 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 199 Intellectual Property 201 The IETF takes no position regarding the validity or scope of any 202 Intellectual Property Rights or other rights that might be claimed to 203 pertain to the implementation or use of the technology described in 204 this document or the extent to which any license under such rights 205 might or might not be available; nor does it represent that it has 206 made any independent effort to identify any such rights. Information 207 on the procedures with respect to rights in RFC documents can be 208 found in BCP 78 and BCP 79. 210 Copies of IPR disclosures made to the IETF Secretariat and any 211 assurances of licenses to be made available, or the result of an 212 attempt made to obtain a general license or permission for the use of 213 such proprietary rights by implementers or users of this 214 specification can be obtained from the IETF on-line IPR repository at 215 http://www.ietf.org/ipr. 217 The IETF invites any interested party to bring to its attention any 218 copyrights, patents or patent applications, or other proprietary 219 rights that may cover technology that may be required to implement 220 this standard. Please address the information to the IETF at 221 ietf-ipr@ietf.org. 223 Acknowledgment 225 Funding for the RFC Editor function is provided by the IETF 226 Administrative Support Activity (IASA).