idnits 2.17.1 draft-ietf-ipngwg-jumbograms-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 9 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. == The 'Obsoletes: ' line in the draft header should list only the _numbers_ of the RFCs which will be obsoleted by this document (if approved); it should not include the word 'RFC' in the list. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. 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 2463 (ref. 'ICMPv6') (Obsoleted by RFC 4443) ** Obsolete normative reference: RFC 2460 (ref. 'IPv6') (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 1981 (ref. 'MTU-DISC') (Obsoleted by RFC 8201) ** Obsolete normative reference: RFC 793 (ref. 'TCP') (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 1323 (ref. 'TCP-EXT') (Obsoleted by RFC 7323) Summary: 10 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT D. Borman, Berkeley Software Design 2 June 25, 1999 S. Deering, Cisco 3 Obsoletes: RFC2147 R. Hinden, Nokia 5 IPv6 Jumbograms 7 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC 2026 [STD-PROC]. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet- Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 This Internet Draft will expire on December 25, 1999. 32 Abstract 34 A "jumbogram" is an IPv6 packet containing a payload longer than 35 65,535 octets. This document describes the IPv6 Jumbo Payload 36 option, which provides the means of specifying such large payload 37 lengths. It also describes the changes needed to TCP and UDP to make 38 use of jumbograms. 40 Jumbograms are relevant only to IPv6 nodes that may be attached to 41 links with a link MTU greater than 65,575 octets, and need not be 42 implemented or understood by IPv6 nodes that do not support 43 attachment to links with such large MTUs. 45 1. Introduction 47 jumbo (jum'bO), 49 n., pl. -bos, adj. 50 -n. 51 1. a person, animal, or thing very large of its kind. 52 -adj. 53 2. very large: the jumbo box of cereal. 55 [1800-10; orig. uncert.; popularized as the name of a large 56 elephant purchased and exhibited by P.T. Barnum in 1882] 58 -- www.infoplease.com 60 The IPv6 header [IPv6] has a 16-bit Payload Length field and, 61 therefore, supports payloads up to 65,535 octets long. This document 62 specifies an IPv6 hop-by-hop option, called the Jumbo Payload option, 63 that carries a 32-bit length field in order to allow transmission of 64 IPv6 packets with payloads between 65,536 and 4,294,967,295 octets in 65 length. Packets with such long payloads are referred to as 66 "jumbograms". 68 The Jumbo Payload option is relevant only for IPv6 nodes that may be 69 attached to links with a link MTU greater than 65,575 octets (that 70 is, 65,535 + 40, where 40 octets is the size of the IPv6 header). 71 The Jumbo Payload option need not be implemented or understood by 72 IPv6 nodes that do not support attachment to links with MTU greater 73 than 65,575. 75 On links with configurable MTUs, the MTU must not be configured to a 76 value greater than 65,575 octets if there are nodes attached to that 77 link that do not support the Jumbo Payload option and it can not be 78 guaranteed that the Jumbo Payload option will not be sent to those 79 nodes. 81 The UDP header [UDP] has a 16-bit Length field which prevents it from 82 making use of jumbograms, and though the TCP header [TCP] does not 83 have a Length field, both the TCP MSS option and the TCP Urgent field 84 are constrained to 16 bits. This document specifies some simple 85 enhancements to TCP and UDP to enable them to make use of jumbograms. 86 An implementation of TCP or UDP on an IPv6 node that supports the 87 Jumbo Payload option must include the enhancements specified here. 89 Note: The 16 bit checksum used by UDP and TCP becomes less accurate 90 as the length of the data being checksummed is increased. 91 Application designers may want to take this into consideration. 93 1.1 Document History 95 This document merges and updates material that was previously 96 published in two separate documents: 98 - The specification of the Jumbo Payload option previously 99 appeared as part of the IPv6 specification in RFC 1883. RFC 100 1883 has been superseded by RFC 2460, which no longer includes 101 specification of the Jumbo Payload option. 103 - The specification of TCP and UDP enhancements to support 104 jumbograms previously appeared as RFC 2147. RFC 2147 is 105 obsoleted by this document. 107 1.2 Requirements 109 The keywords must, must not, required, shall, shall not, should, 110 should not, recommended, may, and optional, if and where they appear 111 in this document, are to be interpreted as described in [KEYWORDS]. 113 2. Format of the Jumbo Payload Option 115 The Jumbo Payload option is carried in an IPv6 Hop-by-Hop Options 116 header, immediately following the IPv6 header. This option has an 117 alignment requirement of 4n + 2. (See [IPv6, Section 4.2] for 118 discussion of option alignment.) The option has the following 119 format: 121 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 122 | Option Type | Opt Data Len | 123 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 124 | Jumbo Payload Length | 125 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 127 Option Type 8-bit value C2 (hexadecimal). 129 Opt Data Len 8-bit value 4. 131 Jumbo Payload Length 32-bit unsigned integer. Length of the IPv6 132 packet in octets, excluding the IPv6 header 133 but including the Hop-by-Hop Options header 134 and any other extension headers present. 135 Must be greater than 65,535. 137 3. Usage of the Jumbo Payload Option 139 The Payload Length field in the IPv6 header must be set to zero in 140 every packet that carries the Jumbo Payload option. 142 If a node that understands the Jumbo Payload option receives a packet 143 whose IPv6 header carries a Payload Length of zero and a Next Header 144 value of zero (meaning that a Hop-by-Hop Options header follows), and 145 whose link-layer framing indicates the presence of octets beyond the 146 IPv6 header, the node must proceed to process the Hop-by-Hop Options 147 header in order to determine the actual length of the payload from 148 the Jumbo Payload option. 150 The Jumbo Payload option must not be used in a packet that carries a 151 Fragment header. 153 Higher-layer protocols that use the IPv6 Payload Length field to 154 compute the value of the Upper-Layer Packet Length field in the 155 checksum pseudo-header described in [IPv6, Section 8.1] must instead 156 use the Jumbo Payload Length field for that computation, for packets 157 that carry the Jumbo Payload option. 159 Nodes that understand the Jumbo Payload option are required to detect 160 a number of possible format errors, and if the erroneous packet was 161 not destined to a multicast address, report the error by sending an 162 ICMP Parameter Problem message [ICMPv6] to the packet's source. The 163 following list of errors specifies the values to be used in the Code 164 and Pointer fields of the Parameter Problem message: 166 error: IPv6 Payload Length = 0 and 167 IPv6 Next Header = Hop-by-Hop Options and 168 Jumbo Payload option not present 170 Code: 0 171 Pointer: high-order octet of the IPv6 Payload Length 173 error: IPv6 Payload Length != 0 and 174 Jumbo Payload option present 176 Code: 0 177 Pointer: Option Type field of the Jumbo Payload option 179 error: Jumbo Payload option present and 180 Jumbo Payload Length < 65,536 182 Code: 0 183 Pointer: high-order octet of the Jumbo Payload Length 185 error: Jumbo Payload option present and 186 Fragment header present 188 Code: 0 189 Pointer: high-order octet of the Fragment header. 191 A node that does not understand the Jumbo Payload option is expected 192 to respond to erroneously-received jumbograms as follows, according 193 to the IPv6 specification: 195 error: IPv6 Payload Length = 0 and 196 IPv6 Next Header = Hop-by-Hop Options 198 Code: 0 199 Pointer: high-order octet of the IPv6 Payload Length 201 error: IPv6 Payload Length != 0 and 202 Jumbo Payload option present 204 Code: 2 205 Pointer: Option Type field of the Jumbo Payload option 207 4. UDP Jumbograms 209 The 16-bit Length field of the UDP header limits the total length of 210 a UDP packet (that is, a UDP header plus data) to no greater than 211 65,535 octets. This document specifies the following modification of 212 UDP to relax that limit: UDP packets longer than 65,535 octets may be 213 sent by setting the UDP Length field to zero, and letting the 214 receiver derive the actual UDP packet length from the IPv6 payload 215 length. (Note that, prior to this modification, zero was not a legal 216 value for the UDP Length field, because the UDP packet length 217 includes the UDP header and therefore has a minimum value of 8.) 219 The specific requirements for sending a UDP jumbogram are as follows: 221 When sending a UDP packet, if and only if the length of the UDP 222 header plus UDP data is greater than 65,535, set the Length field 223 in the UDP header to zero. 225 The IPv6 packet carrying such a large UDP packet will necessarily 226 include a Jumbo Payload option in a Hop-by-Hop Options header; set 227 the Jumbo Payload Length field of that option to be the actual 228 length of the UDP header plus data, plus the length of all IPv6 229 extension headers present between the IPv6 header and the UDP 230 header. 232 For generating the UDP checksum, use the actual length of the UDP 233 header plus data, NOT zero, in the checksum pseudo-header [IPv6, 234 Section 8.1]. 236 The specific requirements for receiving a UDP jumbogram are as 237 follows: 239 When receiving a UDP packet, if and only if the Length field in 240 the UDP header is zero, calculate the actual length of the UDP 241 header plus data from the IPv6 Jumbo Payload Length field minus 242 the length of all extension headers present between the IPv6 243 header and the UDP header. 245 In the unexpected case that the UDP Length field is zero but no 246 Jumbo Payload option is present (i.e., the IPv6 packet is not a 247 jumbogram), use the Payload Length field in the IPv6 header, in 248 place of the Jumbo Payload Length field, in the above calculation. 250 For verifying the received UDP checksum, use the calculated length 251 of the UDP header plus data, NOT zero, in the checksum pseudo- 252 header. 254 5. TCP Jumbograms 256 Because there is no length field in the TCP header, there is nothing 257 limiting the length of an individual TCP packet. However, the MSS 258 value that is negotiated at the beginning of the connection limits 259 the largest TCP packet that can be sent, and the Urgent Pointer 260 cannot reference data beyond 65,535 bytes. 262 5.1 TCP MSS 264 When determining what MSS value to send, if the MTU of the directly 265 attached interface minus 60 [IPv6, Section 8.3] is greater than or 266 equal to 65,535, then set the MSS value to 65,535. 268 When an MSS value of 65,535 is received, it is to be treated as 269 infinity. The actual MSS is determined by subtracting 60 from the 270 value learned by performing Path MTU Discovery [MTU-DISC] over the 271 path to the TCP peer. 273 5.2 TCP Urgent Pointer 275 The Urgent Pointer problem could be fixed by adding a TCP Urgent 276 Pointer Option. However, since it is unlikely that applications 277 using jumbograms will also use Urgent Pointers, a less intrusive 278 change similar to the MSS change will suffice. 280 When a TCP packet is to be sent with an Urgent Pointer (i.e., the URG 281 bit set), first calculate the offset from the Sequence Number to the 282 Urgent Pointer. If the offset is less than 65,535, fill in the 283 Urgent field and continue with the normal TCP processing. If the 284 offset is greater than 65,535, and the offset is greater than or 285 equal to the length of the TCP data, fill in the Urgent Pointer with 286 65,535 and continue with the normal TCP processing. Otherwise, the 287 TCP packet must be split into two pieces. The first piece contains 288 data up to, but not including the data pointed to by the Urgent 289 Pointer, and the Urgent field is set to 65,535 to indicate that the 290 Urgent Pointer is beyond the end of this packet. The second piece 291 can then be sent with the Urgent field set normally. 293 Note: The first piece does not have to include all of the data up 294 to the Urgent Pointer. It can be shorter, just as long as it ends 295 within 65,534 bytes of the Urgent Pointer, so that the offset to 296 the Urgent Pointer in the second piece will be less than 65,535 297 bytes. 299 For TCP input processing, when a TCP packet is received with the URG 300 bit set and an Urgent field of 65,535, the Urgent Pointer is 301 calculated using an offset equal to the length of the TCP data, 302 rather than the offset in the Urgent field. 304 It should also be noted that though the TCP window is only 16-bits, 305 larger windows can be used through use of the TCP Window Scale option 306 [TCP-EXT]. 308 6. Security Considerations 310 The Jumbo Payload option and TCP/UDP jumbograms do not introduce any 311 known new security concerns. 313 7. Authors' Addresses 315 David A. Borman phone: +1 612 405 8194 316 Berkeley Software Design, Inc. email: dab@bsdi.com 317 4719 Weston Hills Drive 318 Eagan, MN 55123 319 USA 321 Stephen E. Deering phone: +1 408 527 8213 322 Cisco Systems, Inc. email: deering@cisco.com 323 170 West Tasman Drive 324 San Jose, CA 95134-1706 325 USA 327 Robert M. Hinden phone: +1 650 625 2004 328 Nokia email: hinden@iprg.nokia.com 329 313 Fairchild Drive 330 Mountain View, CA 94043 331 USA 333 8. References 335 [ICMPv6] Conta, A., S. Deering, ICMP for the Internet Protocol 336 Version 6 (IPv6), RFC 2463, December 1998. 338 [IPv6] Deering, S., R. Hinden, Internet Protocol Version 6 (IPv6) 339 Specification, RFC 2460, December 1998. 341 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 342 Requirement Levels", BCP 14, RFC 2119, March 1997. 344 [MTU-DISC] McCann, J., S. Deering, J. Mogul, Path MTU Discovery for 345 IP Version 6, RFC 1981, August 1986. 347 [STD-PROC] Bradner, S., The Internet Standards Process -- Revision 3, 348 RFC 2026, October 1996. 350 [TCP] Postel, J., Transmission Control Protocol, RFC 793, 351 September 1981. 353 [TCP-EXT] Jacobson, V., R. Braden, D. Borman, "TCP Extensions for 354 High Performance", RFC 1323, May 1992. 356 [UDP] Postel, J., User Datagram Protocol, RFC 768, August 1980. 358 9. Changes from previous version of this draft 360 Version 01 362 - Added note to introduction about reliability of 16 bit TCP/UDP 363 checksum w/ jumbograms. 365 - Made case of "must"'s consistent.