idnits 2.17.1 draft-herbert-6man-icmp-limits-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 : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 208: '... This code SHOULD be sent by an inte...' RFC 2119 keyword, line 221: '... SHOULD be sent when a node discards...' RFC 2119 keyword, line 229: '... long" SHOULD be sent when a node di...' RFC 2119 keyword, line 246: '...xtension header" SHOULD be sent when a...' RFC 2119 keyword, line 255: '... code for "headers too long" SHOULD be...' (6 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 10, 2017) is 2541 days in the past. Is this intentional? Checking references for intended status: Full Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'IPv6' is mentioned on line 172, but not defined == Unused Reference: 'I-D.ietf-6man-rfc2460bis' is defined on line 328, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Downref: Normative reference to an Proposed Standard RFC: RFC 7045 == Outdated reference: A later version (-13) exists of draft-ietf-6man-rfc2460bis-05 Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT T. Herbert 3 Intended Status: Standard Quantonium 4 Expires: November 2017 6 May 10, 2017 8 ICMPv6 errors for discarding packets due to processing limits 9 draft-herbert-6man-icmp-limits-01 11 Abstract 13 Network nodes may discard packets if they are unable to process 14 protocol headers of packets due to processing constraints or limits. 15 When such packets are dropped, the sender receives no indication so 16 it cannot take action to address the cause of discarded packets. This 17 document defines ICMP errors that can be sent by a node that discards 18 packets because it is unable to process the protocol headers. A 19 sender that receives such an ICMP error may be able to modify what it 20 sends in future packets to avoid subsequent packet discards. 22 Status of this Memo 24 This Internet-Draft is submitted to IETF in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF), its areas, and its working groups. Note that 29 other groups may also distribute working documents as 30 Internet-Drafts. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 The list of current Internet-Drafts can be accessed at 38 http://www.ietf.org/1id-abstracts.html 40 The list of Internet-Draft Shadow Directories can be accessed at 41 http://www.ietf.org/shadow.html 43 Copyright and License Notice 45 Copyright (c) 2017 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 1.1 Extension header limits . . . . . . . . . . . . . . . . . . 3 62 1.2 Aggregate header limits . . . . . . . . . . . . . . . . . . 4 63 2 ICMP message format . . . . . . . . . . . . . . . . . . . . . . 4 64 3 Descriptions of codes . . . . . . . . . . . . . . . . . . . . . 5 65 3.1 Unrecognized Next Header type encountered (code 1) . . . . . 5 66 3.2 Extension header too big (code 4) . . . . . . . . . . . . . 5 67 3.3 Extension header chain too long (code 5) . . . . . . . . . . 6 68 3.4 Too many options in extension header (code 6) . . . . . . . 6 69 3.5 Headers too long (code 7) . . . . . . . . . . . . . . . . . 6 70 4 Host response . . . . . . . . . . . . . . . . . . . . . . . . . 6 71 5 Security Considerations . . . . . . . . . . . . . . . . . . . . 7 72 6 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 73 7 References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 74 7.1 Normative References . . . . . . . . . . . . . . . . . . . 8 75 7.2 Informative References . . . . . . . . . . . . . . . . . . 8 76 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8 78 1 Introduction 80 This document specifies ICMP Parameter Problem type errors that can 81 sent when a node discards a packet due to it being unable to process 82 the necessary protocol headers because of processing constraints and 83 limits. 85 Four of the errors are specific to processing limits of extension 86 headers; another error is used when the aggregate protocol headers in 87 a packet exceed the processing limits of a node. 89 1.1 Extension header limits 91 With IPv6, optional internet-layer information is carried in one or 92 more IPv6 Extension Headers [RFC2460]. Extension Headers are placed 93 between the IPv6 header and the Upper-Layer Header in a packet. The 94 term "Header Chain" refers collectively to the IPv6 header, Extension 95 Headers, and Upper-Layer Header occurring in a packet. Individual 96 extension headers may have a length of 2048 and must fit into one 97 MTU. Destination Options and Hop by Hop Options contain a list 98 options in Type-length-value (TLV) format. Each option includes a 99 length of the data field in octets and the minimum size of a (non- 100 pad) option is two bytes and the maximum length is 257 bytes. The 101 number of options in an extension header is only limited by the 102 length of the extension header and MTU. Options may also be skipped 103 over by a receiver if they are unknown and the Option Type indicates 104 to skip (first two bits are 00). 106 Per [RFC2460], except for Hop by Hop options, extension headers are 107 not examined or processed by intermediate nodes. Many intermediate 108 nodes, however, do examine extension header for various purposes. For 109 instance, a node may examine all extension headers to locate the 110 transport header of packet in order to implement transport layer 111 filtering or to track connections to implement a stateful firewall. 113 Destination hosts are expected to process all extensions headers and 114 options in Hop by Hop and Destination Options. 116 Due to the variable lengths and high limits of lengths of extension 117 header and chains, many devices have operational limits of extension 118 headers in packets they can process. [RFC7045] discusses the 119 requirements of intermediate nodes that discard packets because of 120 unrecognized extension headers. When a limit is exceeded, the typical 121 behavior is to silently discard a packet. The limits are non-standard 122 and may be configurable per implementation. Both intermediate nodes 123 and end hosts may institute such limits on extension header 124 processing. 126 This document defines three Parameter Problem codes and extends the 127 applicably of an existing code that are sent by a node that discards 128 a packet due to processing limits of extension headers being 129 exceeded. A source host that receives an ICMP error can modify the 130 use of extension headers in subsequent packets to the destination in 131 order to avoid further occurrences of packets with extension headers 132 being discarded. 134 1.2 Aggregate header limits 136 Many hardware devices implement a parsing buffer of a fixed sized to 137 process packets. The parsing buffer is expected to contain all the 138 headers (often up to a transport layer header for filtering) that a 139 device needs to examine. Parsing buffers have been implemented with 140 various sizes (512 is common, some devices have smaller sizes). 142 When the aggregate length of headers in a packet exceeds the size of 143 the parsing buffer, a device will typically either discard the packet 144 or defer processing to a software slow path. In either case, no 145 indication of a problem is sent back to the sender. 147 This document defines one code for ICMPv6 Parameter Problem type that 148 is sent by a node that is unable to process the headers of a packet 149 due to the aggregate size of the packet headers exceeding a 150 processing limit (e.g. exceeding the size of a parsing buffer). A 151 source host that receives an ICMP error can modify the headers used 152 in subsequent packets to try to avoid further occurrences of packets 153 being discarded or relegated to a slow path. 155 2 ICMP message format 157 The ICMP errors defined in this document are Parameter Problem 158 messages. Four new codes are defined for Parameter Problem type and 159 applicability of one existing code is extended. 161 The format of the ICMP message is: 163 0 1 2 3 164 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 166 | Type | Code | Checksum | 167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 168 | Pointer | 169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 170 | As much of invoking packet | 171 + as possible without the ICMPv6 packet + 172 | exceeding the minimum IPv6 MTU [IPv6] | 173 IPv6 Fields: 175 Destination Address 176 Copied from the Source Address field of the invoking packet. 178 ICMPv6 Fields: 180 Type 181 4 (Parameter Problem type) 183 Code (pertinent to this specification) 184 1 - Unrecognized Next Header type encountered 185 4 - Extension header too big 186 5 - Extension header chain too long 187 6 - Too many options in extension header 188 7 - Headers too long 190 Pointer 191 Identifies the octet offset within the invoking packet where a 192 limit was exceeded. 194 The pointer will point beyond the end of the ICMPv6 packet if 195 the field exceeding the limit is beyond what can fit in the 196 maximum size of an ICMPv6 error message. 198 3 Descriptions of codes 200 3.1 Unrecognized Next Header type encountered (code 1) 202 [RFC2460] specifies that a destination host should send an 203 "unrecognized next header type" when a Next Header value is 204 unrecognized in a packet. This document extends this to allow 205 intermediate nodes to send this same error for a packet that is 206 discarded because a node does not recognize a Next Header type. 208 This code SHOULD be sent by an intermediate node that discards a 209 packet because it encounters a Next Header type that is unknown in 210 its examination. The ICMP Pointer field is set to the offset of the 211 unrecognized value within the original packet. 213 Note that when the original sender receives the ICMP error it can 214 differentiate between the message being sent by a destination host, 215 per [RFC2460], and an error sent by an intermediate host based on 216 matching the source address of the ICMP packet and the destination 217 address of the packet in the ICMP data. 219 3.2 Extension header too big (code 4) 220 An ICMP Parameter Problem with code for "extension header too big" 221 SHOULD be sent when a node discards a packet because the size of 222 extension exceeds its processing limit. The ICMP Pointer field should 223 be set to the offset of length field for the extension header that is 224 too big. 226 3.3 Extension header chain too long (code 5) 228 An ICMP Parameter Problem with code for "extension header chain too 229 long" SHOULD be sent when a node discards a packet with an extension 230 header chain because an extension header chains exceeds it processing 231 limit. The ICMP Pointer field should be set to the offset of the 232 first octet that exceeds the limit. 234 Note there are two different limits that might be applied: a limit on 235 the total size in octets of the header chain, and a limit on the 236 number of extension headers in the chain. This error code is used in 237 both cases. In the case that the an octet limit is exceeded, the ICMP 238 Pointer should be set to first octet beyond the limit. In the case 239 that the number of extension headers is exceeded, the ICMP Pointer 240 should be set to the offset of first octet of the first extension 241 header that is beyond the limit. 243 3.4 Too many options in extension header (code 6) 245 An ICMP Parameter Problem with code for "too many options in 246 extension header" SHOULD be sent when a node discards a packet with 247 an extension header that has a number of options that exceed the 248 processing limits of the node. This code is applicable for 249 Destination options or Hop by Hop options. The ICMP Pointer field 250 should be set to the first octet of the first option that exceeds the 251 limit. 253 3.5 Headers too long (code 7) 255 An ICMP Parameter Problem with code for "headers too long" SHOULD be 256 sent when a node discards a packet because the aggregate length of 257 headers in the packet exceeds the processing limits of the node. The 258 ICMP Pointer should be set to the offset of the first octet that 259 exceeds the limit. 261 4 Host response 263 When a source host receives an ICMP Parameter Problem error for one 264 of the codes described in section 3, it SHOULD verify the ICMP error 265 is valid and take an appropriate action. Possible actions are: 267 * The error SHOULD be logged with sufficient detail for 268 debugging packet loss. The details of the error, including 269 the addresses and the offending extension header or data, 270 should be retained. This would be useful for instance to 271 debug when a node is mis-configured and unexpectedly 272 discarding packets, or when a new extension header is being 273 deployed. 275 * An error SHOULD be reported to an application if the 276 application enabled extension headers for its traffic. The 277 application MAY either terminate a connection if extension 278 headers are required, stop using extension headers in packets 279 to the destination indicated in packet of the ICMP error, or 280 attempt modify its use of extension headers or headers to 281 avoid the packet drop. 283 * A host system SHOULD take action if it is automatically 284 inserting extension headers into packets unbeknownst to the 285 application. The host system SHOULD either stop using 286 extension headers or modify its used of extension headers for 287 subsequent packets sent to the destination indicated in the 288 packet of the ICMP error. 290 5 Security Considerations 292 This document does not introduce any new security concerns for use of 293 ICMP errors. The security considerations for ICMPv6 described in 294 [RFC4443] are applicable. 296 6 IANA Considerations 298 IANA is requested to assign the following codes for ICMPv6 type 4 299 "Parameter Problem": 301 4 - Extension header too big 303 5 - Extension header chain too long 305 6 - Too many options in extension header 307 7 - Headers too long 309 7 References 311 7.1 Normative References 313 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 314 (IPv6) Specification", RFC 2460, December 1998. 316 [RFC7045] Carpenter, B. and S. Jiang, "Transmission and Processing of 317 IPv6 Extension Headers", RFC 7045, DOI 10.17487/RFC7045, 318 December 2013, . 320 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 321 Control Message Protocol (ICMPv6) for the Internet Protocol 322 Version 6 (IPv6) Specification", RFC 4443, DOI 323 10.17487/RFC4443, March 2006, . 326 7.2 Informative References 328 [I-D.ietf-6man-rfc2460bis] Deering, S. and R. Hinden, "Internet 329 Protocol, Version 6 (IPv6) Specification", draft-ietf-6man- 330 rfc2460bis-05. 332 Author's Address 334 Tom Herbert 335 Quantonium 336 Santa Clara, CA 337 USA 339 Email: tom@herbertland.com