Network Working Group D. Borman
Request for Comments: 2675 Berkeley Software Design
Obsoletes: 2147 S. Deering
Category: Standards Track Cisco
R. Hinden
Nokia
August 1999
IPv6 Jumbograms
Network Working Group D. Borman
Request for Comments: 2675 Berkeley Software Design
Obsoletes: 2147 S. Deering
Category: Standards Track Cisco
R. Hinden
Nokia
August 1999
IPv6 Jumbograms
Status of this Memo
本备忘录的状况
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (1999). All Rights Reserved.
版权所有（C）互联网协会（1999年）。版权所有。
Abstract
摘要
A "jumbogram" is an IPv6 packet containing a payload longer than 65,535 octets. This document describes the IPv6 Jumbo Payload option, which provides the means of specifying such large payload lengths. It also describes the changes needed to TCP and UDP to make use of jumbograms.
“巨型程序”是一个包含超过65535个八位字节的有效负载的IPv6数据包。本文档描述了IPv6巨型有效负载选项，该选项提供了指定如此大的有效负载长度的方法。它还描述了使用巨型程序对TCP和UDP所需的更改。
Jumbograms are relevant only to IPv6 nodes that may be attached to links with a link MTU greater than 65,575 octets, and need not be implemented or understood by IPv6 nodes that do not support attachment to links with such large MTUs.
巨型程序仅与可能连接到链路MTU大于65575个八位字节的链路的IPv6节点相关，不支持连接到具有如此大MTU的链路的IPv6节点不需要实现或理解巨型程序。
jumbo (jum'bO),
jumbo（jum'bO），
n., pl. -bos, adj. -n. 1. a person, animal, or thing very large of its kind. -adj. 2. very large: the jumbo box of cereal.
n、 ，pl.-bos，形容词-N1.巨大的人、动物或事物-形容词。2.非常大：一大盒麦片粥。
[1800-10; orig. uncert.; popularized as the name of a large elephant purchased and exhibited by P.T. Barnum in 1882]
[1800-10；起源于uncert.；作为P.T.Barnum在1882年购买并展出的一头大型大象的名字而流行]
-- www.infoplease.com
--www.infoplease.com
The IPv6 header [IPv6] has a 16-bit Payload Length field and, therefore, supports payloads up to 65,535 octets long. This document specifies an IPv6 hop-by-hop option, called the Jumbo Payload option, that carries a 32-bit length field in order to allow transmission of IPv6 packets with payloads between 65,536 and 4,294,967,295 octets in length. Packets with such long payloads are referred to as "jumbograms".
IPv6报头[IPv6]有一个16位有效负载长度字段，因此支持最长为65535个八位字节的有效负载。本文档指定了一个IPv6逐跳选项，称为Jumbo Payload option，该选项携带一个32位长度字段，以便允许传输有效负载长度在65536和4294967295个八位字节之间的IPv6数据包。具有如此长有效载荷的数据包被称为“巨型程序”。
The Jumbo Payload option is relevant only for IPv6 nodes that may be attached to links with a link MTU greater than 65,575 octets (that is, 65,535 + 40, where 40 octets is the size of the IPv6 header). The Jumbo Payload option need not be implemented or understood by IPv6 nodes that do not support attachment to links with MTU greater than 65,575.
Jumbo Payload选项仅适用于连接到链路MTU大于65575个八位字节（即65535+40，其中40个八位字节是IPv6报头的大小）的链路的IPv6节点。不支持连接到MTU大于65575的链路的IPv6节点不需要实现或理解巨型有效负载选项。
On links with configurable MTUs, the MTU must not be configured to a value greater than 65,575 octets if there are nodes attached to that link that do not support the Jumbo Payload option and it can not be guaranteed that the Jumbo Payload option will not be sent to those nodes.
在具有可配置MTU的链路上，如果连接到该链路的节点不支持巨型有效负载选项，并且无法保证巨型有效负载选项不会发送到这些节点，则MTU不得配置为大于65575个八位字节的值。
The UDP header [UDP] has a 16-bit Length field which prevents it from making use of jumbograms, and though the TCP header [TCP] does not have a Length field, both the TCP MSS option and the TCP Urgent field are constrained to 16 bits. This document specifies some simple enhancements to TCP and UDP to enable them to make use of jumbograms. An implementation of TCP or UDP on an IPv6 node that supports the Jumbo Payload option must include the enhancements specified here.
UDP头[UDP]有一个16位的长度字段，防止它使用巨型程序，尽管TCP头[TCP]没有长度字段，但TCP MSS选项和TCP紧急字段都被限制为16位。本文档指定了对TCP和UDP的一些简单增强，以使它们能够使用巨型程序。支持Jumbo有效负载选项的IPv6节点上的TCP或UDP实现必须包括此处指定的增强功能。
Note: The 16 bit checksum used by UDP and TCP becomes less accurate as the length of the data being checksummed is increased. Application designers may want to take this into consideration.
注意：UDP和TCP使用的16位校验和随着校验和数据长度的增加而变得不准确。应用程序设计人员可能需要考虑这一点。
This document merges and updates material that was previously published in two separate documents:
本文档合并并更新了以前在两个单独文档中发布的资料：
- The specification of the Jumbo Payload option previously appeared as part of the IPv6 specification in RFC 1883. RFC 1883 has been superseded by RFC 2460, which no longer includes specification of the Jumbo Payload option.
- 巨型有效负载选项的规范以前作为IPv6规范的一部分出现在RFC1883中。RFC1883已被RFC2460取代，不再包括巨型有效载荷选项的规范。
- The specification of TCP and UDP enhancements to support jumbograms previously appeared as RFC 2147. RFC 2147 is obsoleted by this document.
- 支持巨型程序的TCP和UDP增强规范以前显示为RFC 2147。RFC 2147已被本文件淘汰。
The Jumbo Payload option is carried in an IPv6 Hop-by-Hop Options header, immediately following the IPv6 header. This option has an alignment requirement of 4n + 2. (See [IPv6, Section 4.2] for discussion of option alignment.) The option has the following format:
Jumbo有效负载选项在IPv6逐跳选项标头中携带，紧跟在IPv6标头之后。该选项的对齐要求为4n+2。（有关选项对齐的讨论，请参见[IPv6，第4.2节。）该选项具有以下格式：
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Opt Data Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Jumbo Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Opt Data Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Jumbo Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Option Type 8-bit value C2 (hexadecimal).
选项类型8位值C2（十六进制）。
Opt Data Len 8-bit value 4.
Opt Data Len 8位值4。
Jumbo Payload Length 32-bit unsigned integer. Length of the IPv6 packet in octets, excluding the IPv6 header but including the Hop-by-Hop Options header and any other extension headers present. Must be greater than 65,535.
巨型有效负载长度32位无符号整数。IPv6数据包的长度（以八位字节为单位），不包括IPv6标头，但包括逐跳选项标头和存在的任何其他扩展标头。必须大于65535。
The Payload Length field in the IPv6 header must be set to zero in every packet that carries the Jumbo Payload option.
在每个携带Jumbo Payload选项的数据包中，IPv6报头中的Payload Length字段必须设置为零。
If a node that understands the Jumbo Payload option receives a packet whose IPv6 header carries a Payload Length of zero and a Next Header value of zero (meaning that a Hop-by-Hop Options header follows), and whose link-layer framing indicates the presence of octets beyond the IPv6 header, the node must proceed to process the Hop-by-Hop Options header in order to determine the actual length of the payload from the Jumbo Payload option.
如果理解Jumbo Payload option的节点接收到一个数据包，该数据包的IPv6报头携带的有效负载长度为零，下一个报头值为零（意味着随后是逐跳选项报头），并且其链路层帧表示IPv6报头之外存在八位字节，节点必须继续处理逐跳选项报头，以便根据巨型有效负载选项确定有效负载的实际长度。
The Jumbo Payload option must not be used in a packet that carries a Fragment header.
Jumbo Payload选项不得用于携带片段头的数据包中。
Higher-layer protocols that use the IPv6 Payload Length field to compute the value of the Upper-Layer Packet Length field in the checksum pseudo-header described in [IPv6, Section 8.1] must instead use the Jumbo Payload Length field for that computation, for packets that carry the Jumbo Payload option.
使用IPv6有效负载长度字段来计算[IPv6，第8.1节]中所述校验和伪报头中上层数据包长度字段值的更高层协议必须改为使用巨型有效负载长度字段来进行该计算，用于携带巨型有效负载选项的数据包。
Nodes that understand the Jumbo Payload option are required to detect a number of possible format errors, and if the erroneous packet was not destined to a multicast address, report the error by sending an ICMP Parameter Problem message [ICMPv6] to the packet's source. The following list of errors specifies the values to be used in the Code and Pointer fields of the Parameter Problem message:
理解Jumbo Payload选项的节点需要检测许多可能的格式错误，如果错误的数据包没有发送到多播地址，则通过向数据包的源发送ICMP参数问题消息[ICMPv6]来报告错误。以下错误列表指定了要在参数问题消息的代码和指针字段中使用的值：
error: IPv6 Payload Length = 0 and IPv6 Next Header = Hop-by-Hop Options and Jumbo Payload option not present
错误：IPv6有效负载长度=0，IPv6下一个标头=逐跳选项和巨型有效负载选项不存在
Code: 0 Pointer: high-order octet of the IPv6 Payload Length
代码：0指针：IPv6有效负载长度的高阶八位字节
error: IPv6 Payload Length != 0 and Jumbo Payload option present
错误：IPv6有效负载长度！=存在0和巨型有效负载选项
Code: 0 Pointer: Option Type field of the Jumbo Payload option
代码：0指针：巨型有效负载选项的选项类型字段
error: Jumbo Payload option present and Jumbo Payload Length < 65,536
错误：存在巨型有效负载选项，且巨型有效负载长度<65536
Code: 0 Pointer: high-order octet of the Jumbo Payload Length
代码：0指针：巨型有效负载长度的高阶八位字节
error: Jumbo Payload option present and Fragment header present
错误：存在巨型有效负载选项，并且存在片段头
Code: 0 Pointer: high-order octet of the Fragment header.
代码：0指针：片段头的高阶八位字节。
A node that does not understand the Jumbo Payload option is expected to respond to erroneously-received jumbograms as follows, according to the IPv6 specification:
根据IPv6规范，不理解Jumbo Payload（巨型有效负载）选项的节点预计会对错误接收的巨型程序做出如下响应：
error: IPv6 Payload Length = 0 and IPv6 Next Header = Hop-by-Hop Options
错误：IPv6有效负载长度=0，IPv6下一个标头=逐跳选项
Code: 0 Pointer: high-order octet of the IPv6 Payload Length
代码：0指针：IPv6有效负载长度的高阶八位字节
error: IPv6 Payload Length != 0 and Jumbo Payload option present
错误：IPv6有效负载长度！=存在0和巨型有效负载选项
Code: 2 Pointer: Option Type field of the Jumbo Payload option
代码：2指针：巨型有效负载选项的选项类型字段
The 16-bit Length field of the UDP header limits the total length of a UDP packet (that is, a UDP header plus data) to no greater than 65,535 octets. This document specifies the following modification of UDP to relax that limit: UDP packets longer than 65,535 octets may be sent by setting the UDP Length field to zero, and letting the receiver derive the actual UDP packet length from the IPv6 payload length. (Note that, prior to this modification, zero was not a legal value for the UDP Length field, because the UDP packet length includes the UDP header and therefore has a minimum value of 8.)
UDP报头的16位长度字段将UDP数据包（即UDP报头加数据）的总长度限制为不超过65535个八位字节。本文档规定了对UDP的以下修改，以放宽该限制：通过将UDP长度字段设置为零，并让接收方从IPv6有效负载长度推导出实际UDP数据包长度，可以发送长度超过65535个八位字节的UDP数据包。（注意，在此修改之前，零不是UDP长度字段的合法值，因为UDP数据包长度包括UDP报头，因此最小值为8。）
The specific requirements for sending a UDP jumbogram are as follows:
发送UDP巨型程序的具体要求如下：
When sending a UDP packet, if and only if the length of the UDP header plus UDP data is greater than 65,535, set the Length field in the UDP header to zero.
发送UDP数据包时，如果且仅当UDP报头加UDP数据的长度大于65535，请将UDP报头中的长度字段设置为零。
The IPv6 packet carrying such a large UDP packet will necessarily include a Jumbo Payload option in a Hop-by-Hop Options header; set the Jumbo Payload Length field of that option to be the actual length of the UDP header plus data, plus the length of all IPv6 extension headers present between the IPv6 header and the UDP header.
承载如此大的UDP分组的IPv6分组将必然在逐跳选项报头中包括巨型有效负载选项；将该选项的Jumbo Payload Length字段设置为UDP标头加上数据的实际长度，再加上IPv6标头和UDP标头之间存在的所有IPv6扩展标头的长度。
For generating the UDP checksum, use the actual length of the UDP header plus data, NOT zero, in the checksum pseudo-header [IPv6, Section 8.1].
要生成UDP校验和，请使用UDP报头的实际长度加上校验和伪报头中的数据，而不是零[IPv6，第8.1节]。
The specific requirements for receiving a UDP jumbogram are as follows:
接收UDP巨型图的具体要求如下：
When receiving a UDP packet, if and only if the Length field in the UDP header is zero, calculate the actual length of the UDP header plus data from the IPv6 Jumbo Payload Length field minus the length of all extension headers present between the IPv6 header and the UDP header.
接收UDP数据包时，如果且仅当UDP报头中的长度字段为零，则计算UDP报头的实际长度加上来自IPv6 Jumbo Payload Length字段的数据减去IPv6报头和UDP报头之间存在的所有扩展报头的长度。
In the unexpected case that the UDP Length field is zero but no Jumbo Payload option is present (i.e., the IPv6 packet is not a jumbogram), use the Payload Length field in the IPv6 header, in place of the Jumbo Payload Length field, in the above calculation.
在UDP长度字段为零但不存在巨型有效负载选项的意外情况下（即IPv6数据包不是巨型程序），在上述计算中使用IPv6报头中的有效负载长度字段代替巨型有效负载长度字段。
For verifying the received UDP checksum, use the calculated length of the UDP header plus data, NOT zero, in the checksum pseudo-header.
为了验证收到的UDP校验和，请使用UDP报头的计算长度加上校验和伪报头中的数据，而不是零。
Because there is no length field in the TCP header, there is nothing limiting the length of an individual TCP packet. However, the MSS value that is negotiated at the beginning of the connection limits the largest TCP packet that can be sent, and the Urgent Pointer cannot reference data beyond 65,535 bytes.
由于TCP报头中没有长度字段，因此没有任何内容限制单个TCP数据包的长度。但是，连接开始时协商的MSS值限制了可以发送的最大TCP数据包，并且紧急指针不能引用超过65535字节的数据。
When determining what MSS value to send, if the MTU of the directly attached interface minus 60 [IPv6, Section 8.3] is greater than or equal to 65,535, then set the MSS value to 65,535.
在确定要发送的MSS值时，如果直接连接接口的MTU减去60[IPv6，第8.3节]大于或等于65535，则将MSS值设置为65535。
When an MSS value of 65,535 is received, it is to be treated as infinity. The actual MSS is determined by subtracting 60 from the value learned by performing Path MTU Discovery [MTU-DISC] over the path to the TCP peer.
当收到MSS值65535时，将其视为无穷大。实际的MSS是通过在到TCP对等方的路径上执行路径MTU发现[MTU-DISC]而获得的值减去60来确定的。
The Urgent Pointer problem could be fixed by adding a TCP Urgent Pointer Option. However, since it is unlikely that applications using jumbograms will also use Urgent Pointers, a less intrusive change similar to the MSS change will suffice.
通过添加TCP紧急指针选项，可以解决紧急指针问题。但是，由于使用巨型程序的应用程序不太可能同时使用紧急指针，因此，类似于MSS更改的侵入性较小的更改就足够了。
When a TCP packet is to be sent with an Urgent Pointer (i.e., the URG bit set), first calculate the offset from the Sequence Number to the Urgent Pointer. If the offset is less than 65,535, fill in the Urgent field and continue with the normal TCP processing. If the offset is greater than 65,535, and the offset is greater than or equal to the length of the TCP data, fill in the Urgent Pointer with 65,535 and continue with the normal TCP processing. Otherwise, the TCP packet must be split into two pieces. The first piece contains data up to, but not including the data pointed to by the Urgent Pointer, and the Urgent field is set to 65,535 to indicate that the Urgent Pointer is beyond the end of this packet. The second piece can then be sent with the Urgent field set normally.
当TCP数据包与紧急指针（即URG位集）一起发送时，首先计算从序列号到紧急指针的偏移量。如果偏移量小于65535，请填写紧急字段并继续正常的TCP处理。如果偏移量大于65535，并且偏移量大于或等于TCP数据的长度，请用65535填充紧急指针，然后继续正常的TCP处理。否则，TCP数据包必须分成两部分。第一部分包含的数据最多为，但不包括紧急指针指向的数据，紧急字段设置为65535，以指示紧急指针超出此数据包的末尾。然后，可以发送第二件，并将紧急字段设置为正常。
Note: The first piece does not have to include all of the data up to the Urgent Pointer. It can be shorter, just as long as it ends within 65,534 bytes of the Urgent Pointer, so that the offset to the Urgent Pointer in the second piece will be less than 65,535 bytes.
注：第一部分不必包括紧急指针之前的所有数据。它可以更短，只要它在紧急指针的65534字节内结束，那么第二段中紧急指针的偏移量将小于65535字节。
For TCP input processing, when a TCP packet is received with the URG bit set and an Urgent field of 65,535, the Urgent Pointer is calculated using an offset equal to the length of the TCP data, rather than the offset in the Urgent field.
对于TCP输入处理，当接收到带有URG位集和65535紧急字段的TCP数据包时，使用等于TCP数据长度的偏移量（而不是紧急字段中的偏移量）计算紧急指针。
It should also be noted that though the TCP window is only 16-bits, larger windows can be used through use of the TCP Window Scale option [TCP-EXT].
还应注意，尽管TCP窗口只有16位，但通过使用TCP窗口缩放选项[TCP-EXT]，可以使用较大的窗口。
The Jumbo Payload option and TCP/UDP jumbograms do not introduce any known new security concerns.
巨型有效负载选项和TCP/UDP巨型程序不会引入任何已知的新安全问题。
David A. Borman Berkeley Software Design, Inc. 4719 Weston Hills Drive Eagan, MN 55123 USA
David A.Borman Berkeley软件设计有限公司，地址：美国明尼苏达州伊根韦斯顿山大道4719号，邮编：55123
Phone: +1 612 405 8194
EMail: dab@bsdi.com
Phone: +1 612 405 8194
EMail: dab@bsdi.com
Stephen E. Deering Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706 USA
Stephen E.Deering Cisco Systems，Inc.美国加利福尼亚州圣何塞西塔斯曼大道170号，邮编95134-1706
Phone: +1 408 527 8213
EMail: deering@cisco.com
Phone: +1 408 527 8213
EMail: deering@cisco.com
Robert M. Hinden Nokia 313 Fairchild Drive Mountain View, CA 94043 USA
Robert M.Hinden诺基亚313飞兆半导体山景大道，加利福尼亚州94043
Phone: +1 650 625 2004
EMail: hinden@iprg.nokia.com
Phone: +1 650 625 2004
EMail: hinden@iprg.nokia.com
[ICMPv6] Conta, A. and S. Deering, "ICMP for the Internet Protocol Version 6 (IPv6)", RFC 2463, December 1998.
[ICMPv6]Conta，A.和S.Deering，“互联网协议第6版（IPv6）的ICMP”，RFC 2463，1998年12月。
[IPv6] Deering, S. and R. Hinden, "Internet Protocol Version 6 (IPv6) Specification", RFC 2460, December 1998.
[IPv6]Deering，S.和R.Hinden，“互联网协议版本6（IPv6）规范”，RFC 2460，1998年12月。
[MTU-DISC] McCann, J., Deering, S. and J. Mogul, "Path MTU Discovery for IP Version 6", RFC 1981, August 1986.
[MTU-DISC]McCann，J.，Deering，S.和J.Mogul，“IP版本6的路径MTU发现”，RFC 1981，1986年8月。
[TCP] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[TCP]Postel，J.，“传输控制协议”，STD 7，RFC 793，1981年9月。
[TCP-EXT] Jacobson, V., Braden, R. and D. Borman, "TCP Extensions for High Performance", RFC 1323, May 1992.
[TCP-EXT]Jacobson，V.，Braden，R.和D.Borman，“高性能TCP扩展”，RFC 1323，1992年5月。
[UDP] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
[UDP]Postel，J.，“用户数据报协议”，STD 6，RFC 768，1980年8月。
Copyright (C) The Internet Society (1999). All Rights Reserved.
版权所有（C）互联网协会（1999年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。