idnits 2.17.1 draft-fuller-240space-02.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 203. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 214. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 221. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 227. 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 9 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 (March 24, 2008) is 5870 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: September 25, 2008 March 24, 2008 8 Reclassifying 240/4 as usable unicast address space 9 draft-fuller-240space-02.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 September 25, 2008. 36 Abstract 38 This memo reclassifies the address block 240.0.0.0/4 as usable 39 address space. While the community has not concluded whether the 40 block should be considered public or private, given the current 41 consumption rate, it is clear that the block should not be left 42 unused. This document also makes several recommendations on ways 43 that current implementations of the IP protocol stack will need to be 44 modified to make this address space usable. 46 1. Introduction 48 Recent estimates [1] indicate that the Internet Assigned Numbers 49 Authority (IANA) will exhaust the unallocated pool of 32-bit IPv4 50 addresses some time sometime between 2008 and 2010. As that time 51 rapidly approaches, the Internet community must consider what it 52 should do with address space currently reserved for future use. 53 [RFC3330] states that the address range 240.0.0.0/4 is reserved for 54 future use. There are several possible uses of this block. One 55 would be to reclassify the block as private address space, as defined 56 in [RFC1918], so that large private organizations that have outgrown 57 the other private blocks have additional room for network expansion. 58 Another possibility is for the address space to be made available for 59 public Internet use. A decision on which of these alternatives (if 60 either) is chosen requires additional analysis and debate; what is 61 clear, though, is that today's IP protocol stack implementations will 62 need to be modified to support any use of the currently-reserved 63 space as most today return errors when such addresses are used. 65 This memo requires implementors to make the changes necessary to 66 receive, transmit, and forward packets that contain addresses in this 67 block as if they were within any other unicast address block. 69 It is envisioned that the utility of this block will grow over time. 70 Some devices may never be able to use it as their IP implementations 71 have no update mechanism. This is not to say that the block will 72 find no use. For example, home implementations that make use of 73 network address translation [RFC2766] can also make use of this range 74 as their public facing address once the resources that people wish to 75 access have been updated. Similarly, an organization building a new, 76 private network (one with no need to communicate with other parts of 77 the Internet), may benefit from the availability of this address 78 space. 80 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 81 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 82 document are to be interpreted as described in [RFC2119]. 84 2. Implementation considerations 86 At the present time, most IP implementations consider any IP address 87 in the range 240.0.0.0 through 255.255.255.255 to be invalid as the 88 source or destination of a datagram. The check for such "illegal" 89 addresses may occur in many places, including at datagram receipt, 90 before IP datagram transmission, when an IP address is assigned to a 91 network interface, or even by router and firewall configuration 92 parsers. Because 240.0.0.0/4 is henceforth reclassified as usable 93 address space, implementations MUST treat this range as they would 94 any other unicast address range. Implementors should review their 95 implementation for these and other restrictions on the use of 96 240.0.0.0/4 and remove as appropriate. 98 How the check is implemented may vary, but a common method is to 99 treat the IP address as a 32-bit quantity in network byte order, 100 performing a logical AND operation with the value hexadecimal 101 F0000000, and testing to see if the result is hexadecimal F0000000. 102 If the test succeeds, the address is rejected. 104 Note that the broadcast address, 255.255.255.255, still must be 105 treated specially in each case: it is illegal as a source IP address, 106 it is illegal as an network interface address, and it matches the 107 local system when used as the destination address in a received 108 datagram. 110 3. Implementation status 112 As of the release of the second version of this draft, Apple OSX has 113 been confirmed to support the use of 240.0.0.0/4 as unicast address 114 space. Changes have been incorporated into recent versions of Sun 115 Solaris and have been submitted for inclusion in the Linux kernel 116 tree. No plans have been announced for modifications to any version 117 of Microsoft Windows, in part because of uncertainty over how to 118 perform 6-to-4 tunneling in the absence of a definitive statement on 119 whether 240.0.0.0/4 is "public" or "private" space. 121 4. Security Considerations 123 The reclassification of 240.0.0.0/4 as a unicast block presents the 124 same security issues as any other unicast block, with the possible 125 addition that attackers may attempt to exploit poorly developed 126 security software that cannot handle the change. The authors have 127 not explored whether such implementations exist. 129 5. IANA Considerations 131 Although this memo requires implementations to treat addresses in the 132 range 240.0.0.0/4 the same as any other unicast addresses, it does 133 not change the "reserved" status of the 240.0.0.0/4 address block. 134 The IANA is requested to continue to reserve this block for future 135 use, with the understanding that future standards action will define 136 how it is to be allocated. 138 6. References 140 6.1. Normative References 142 [RFC3330] IANA, "Special-Use IPv4 Addresses", RFC 3330, 143 September 2002. 145 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 146 Requirement Levels", RFC 2119, March 1997. 148 6.2. Informative References 150 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., 151 and E. Lear, "Address Allocation for Private Internets", 152 RFC 1918, February 1996. 154 [RFC2766] Tsirtsis, G. and P. Srisuresh, "Network Address 155 Translation - Protocol Translation", RFC 2766, 156 February 2000. 158 URIs 160 [1] 162 Appendix A. Changes 164 Authors' Addresses 166 Vince Fuller 167 Cisco Systems 168 Tasman Drive 169 San Jose, CA 95134 170 USA 172 Email: vaf@cisco.com 174 Eliot Lear 175 Cisco Systems 176 Glatt-com, 2nd Floor 177 Glattzentrum, Zurich 8301 178 Switzerland 180 Email: lear@cisco.com 181 David Meyer 182 Cisco Systems 183 Tasman Drive 184 San Jose, CA 95134 185 USA 187 Email: dmm@cisco.com 189 Full Copyright Statement 191 Copyright (C) The IETF Trust (2008). 193 This document is subject to the rights, licenses and restrictions 194 contained in BCP 78, and except as set forth therein, the authors 195 retain all their rights. 197 This document and the information contained herein are provided on an 198 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 199 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 200 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 201 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 202 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 203 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 205 Intellectual Property 207 The IETF takes no position regarding the validity or scope of any 208 Intellectual Property Rights or other rights that might be claimed to 209 pertain to the implementation or use of the technology described in 210 this document or the extent to which any license under such rights 211 might or might not be available; nor does it represent that it has 212 made any independent effort to identify any such rights. Information 213 on the procedures with respect to rights in RFC documents can be 214 found in BCP 78 and BCP 79. 216 Copies of IPR disclosures made to the IETF Secretariat and any 217 assurances of licenses to be made available, or the result of an 218 attempt made to obtain a general license or permission for the use of 219 such proprietary rights by implementers or users of this 220 specification can be obtained from the IETF on-line IPR repository at 221 http://www.ietf.org/ipr. 223 The IETF invites any interested party to bring to its attention any 224 copyrights, patents or patent applications, or other proprietary 225 rights that may cover technology that may be required to implement 226 this standard. Please address the information to the IETF at 227 ietf-ipr@ietf.org.