Network Working Group Robert Elz Internet Draft University of Melbourne Expiration Date: September 1995 March 1995 The IPv6 Payload Header draft-kre-ipv6-payload-00.txt 1. Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). 2. Abstract This draft suggests a method by which many IP payload data bodies may be encapsulated in a single IPv6 datagram. New headers, designed with IPv6 in mind, will all contain a ``next header'' field, allowing headers to be chained, however older header types, inherited from IPv4, such as TCP and UDP, do not contain this field, meaning that without assistance, they would have to be the last header in any sequence, and only one such header could appear in a packet. This draft provides the mechanism to overcome this difficulty. kre [Page 1] Internet Draft draft-kre-ipv6-payload-00.txt March 1995 3. Introduction The IPv6 header structure is designed to permit any number of headers to be chained together, all IPv6 headers contain a ``next header'' field to permit this. TCP, UDP, and currently at least, ICMP, have no such field. This implies that such headers must be last in the IPv6 header sequence, and consequently, that only one of these headers can be present in an IPv6 datagram. The limitation of, in particular, only one TCP segment in an IP datagram has been noted previously, and for IPv4 a mechanism to overcome this limitation has been proposed before [RFC1692 - TMux]. It seems, however, that with the significantly more general IPv6 header mechanisms a more general solution to this problem is easily achievable, this memo proposes a mechanism. The relationship between this mechanism, and TMUX is discussed more in section 15. 4. New Headers Two new, virtually identical, IPv6 headers are proposed to implement the functionality required. Each contains a next header field to allow chaining to further IPv6 headers, often, though without being required, more of these new headers. The header is followed, after some padding for alignment in one form, by a data field, defined as carrying other IPv6 protocol data, which is interpreted just as if the payload header, and any other similar headers earlier in the packet, had not existed, and the packet ended at the point where the enclosed data ends. The headers also contain a payload type field, giving the IP protocol number of the (first) enclosed header, and a length field, giving the length, in octets, of the enclosed headers and data, exclusive of any padding. 5. The General Payload Header 0 7 8 15 16 31 ----------------------------------------------------------------- | | | | | Nxt Hdr | Payload Type | Length | | | | | ----------------------------------------------------------------- | | | Data (Length octets) ... | | | | /------------------------------------| | / Trailing Padding | -------------------------/--------------------------------------- The two new headers are distinguished by only one feature. With the kre [Page 2] Internet Draft draft-kre-ipv6-payload-00.txt March 1995 first, the ``General Payload Header'' (GPH) the first octet of the next header follows immediately after the length field. That is, assuming the standard convention that IPv6 headers are always aligned at an offset that is a multiple of 8 octets from the start of the IPv6 header, the enclosed header will be located at an offset that is a multiple of 4, but not a multiple of 8 from that point. This turns out to be ideal for TCP, whose normal header size is 20 octets, a multiple of 4 that is not a multiple of 8, causing the user data to be aligned at a multiple of 8 offset from the start of the packet. This matches the behaviour of IPv4, where the 20 octet IP header, and 20 octet TCP header, in the usual case, worked together to place the user data 40 octets from the start of the packet a multiple of 8. This header also uses minimum achievable space, conserving packet size, for those enclosed payloads that do not require any particular alignment greater than a multiple of 4. UDP and ICMP both fit into that category. 6. The Aligned Payload Header 0 7 8 15 16 31 ----------------------------------------------------------------- | | | | | Nxt Hdr | Payload Type | Length | | | | | ----------------------------------------------------------------- | | | Alignment Padding | | | ----------------------------------------------------------------- | | | Data (Length octets) ... | | | | /------------------------------------| | / Trailing Padding | -------------------------/--------------------------------------- The second header, the ``Aligned Payload Header'' (APH) is formed from the GPH by inserting 4 octets of padding. The Alignment Padding field should be set to zero before transmission. This causes the following header, as specified by the Payload Header field to be aligned at a multiple of 8 octets from the start of the packet. This permits any IPv6 header to be enclosed, with almost no restriction. kre [Page 3] Internet Draft draft-kre-ipv6-payload-00.txt March 1995 7. Wild Idea An alternative form for the APH would be to specify that the Alignment Padding field contain the number of octets of padding included, allowing any number of padding octets. This would allow co-operating implementations to agree, via mechanisms yet to be defined, to commence their user data in the enclosed payload at any desired offset from the start of the packet. In particular, where jumbograms are being transmitted, and maximal efficiency is desired, inserting many thousands of octets of padding may be useful to cause the eventual application data to arrive aligned at a page boundary of the recipient host, permitting very rapid movement of the data into application address space. Whether this might be useful or not is for further study. For now we shall simply define the four octet field following the APH, as containing, in network byte order, the number of bytes of additional padding following those four octets. If the four octet ``Alignment Padding'' field contains all zeroes, the meaning will be the same as if this section were deleted completely. 8. Header Values The IP header types for the GPH and APH are to be defined by the IANA. 9. Header Fields Both the GPH and APH headers contain fields with the following meanings. 9.1. Next Header This 8 bit field contains the protocol type of the header that immediately follows the Payload Header and associated data. Its value is taken from the list of IP protocol types regularly published by the IANA. 9.2. Payload Type This 8 bit field contains the protocol type of the header that is to enclosed at the start of the data field covered by the payload header. Its value is taken from the list of IP protocol types regularly published by the IANA. In the case of the General Payload Header, only those IP protocol types not constrained to begin at an offset of a multiple of 8 octets from the start of the packet are permitted. kre [Page 4] Internet Draft draft-kre-ipv6-payload-00.txt March 1995 9.3. Length This 16 bit field, in network byte order, that is, with the most significant octet transmitted first, gives the number of octets of data in the enclosed data field. This counts octets following the payload header, and any interposed alignment padding. Any value between 0 and 65535 that is consistent with the enclosed data, and the length of the enclosing packet is permitted. 9.4. Data This field is of length given by the ``Length'' field, and commences immediately after the Payload Header, and any interposed alignment padding. The first octet of this field is also the first octet of a header of the type defined by the ``Payload Type'' field. If the length of this field, plus the sizes of the Payload Header itself, and any alignment padding, is not a multiple of 8, then enough additional octets, of undefined content or meaning, are appended to cause the overall length of the total structure to be a multiple of 8. The ``Length'' field does not include these additional octets, if any. At most 7, and of course, no less than 0, such additional octets are added. 10. Limitations The longest enclosed payload that can be carried by this scheme is 65535 octets, there is no convention to permit extending the payload to a size greater than this. It is considered unlikely that there would ever be a meaningful use for sending multiple payloads, each greater than 65535 octets in a single datagram - a single such payload can of course be carried without the payload header, and with, or without, preceding smaller payloads. Note that to carry a payload longer than 65527 octets, or perhaps shorter, depending upon intervening headers, the enclosing IPv6 header must be in jumbogram format, with zero in the IPv6 header ``payload length'' field, and the actual length in a hop-by-hop option. kre [Page 5] Internet Draft draft-kre-ipv6-payload-00.txt March 1995 11. Use of Payload Headers The data field following a payload header may contain any header valid in an IPv6 packet, other than those intended to be examined by nodes other than the ultimate source and destination of the packet. Note that this does not preclude enclosing encapsulated IPv6 datagrams as objects carried in a payload header, such being, for this purpose anyway, considered to be two separate transactions, one between the ultimate source and destination of the encapsulated packet, and one between the entity encapsulating, and the entity decapsulating. However IPv6 routing header, hop-by-hop options, and fragmentation headers, not within an encapsulated IPv6 packet, are undefined within a Payload Header. Any node that receives such a packet may ignore the packet, return an ICMP parameter problem, with the pointer indicating the first octet of the undefined header encountered, or continue processing the packet as if the payload header was not present, at its option. 12. Semantics A Node receiving an IPv6 datagram containing a payload header should process the datagram in the usual way until the payload header is the next header to be processed. It should then process the body of the payload header as if the payload header was absent, and the first octet of the enclosed data immediately followed the last octet preceding the payload header, and the payload length of the original IPv6 datagram were the sum of the sizes of the headers (if any) between the IPv6 header and the payload header, and the length field of the payload header. Any headers already correctly processed are assumed to have been correctly processed for the shortened datagram without reprocessing. For example, if an authentication header had been processed already, the shortened datagram is authenticated, regardless of whether the signature in the authentication header would have been matched correctly with one computed over the shortened datagram (which we presume it would not.) Having completed processing of the enclosed payload header, the remainder of the original datagram, if any, is processed as if the payload header, and its enclosed contents were never a part of the datagram, and the IPv6 header payload length field were decreased by the total length of the payload header, its enclosed data, and interposed and trailing alignment octets, if any. Again, any headers processed correctly before the payload header are assumed to have been correctly processed for the new shortened packet. On the other hand, headers that were processed while processing the payload header are presumed not to have existed in so far as they affect the kre [Page 6] Internet Draft draft-kre-ipv6-payload-00.txt March 1995 processing of the remainder of this packet, as distinct from any changes they may have made to the global state of the node, or particular communications between the two concerned participating nodes. For example, an authentication header enclosed by a payload header authenticates only the data enclosed in that payload header, and has no relevance at all to other data in the original datagram. On the other hand an enclosed TCP header may update the the sequence or acknowledgement numbers of a connection, that update persists beyond the processing of the payload. A packet containing a payload header shall be semantically equivalent to two packets, received in the order that they are present in the combined packet - that is, the body of the payload first, and the rest of the packet second, with suitable adjustments assumed to have been made to all headers that precede the payload header to make them appropriate to each of the resulting packets. 13. ICMP processing If it should become necessary to send an ICMP error packet in response to a received packet containing a payload header, the returned packet contents shall be the original IPv6 packet, or as much of it as will fit in the ICMP packet being returned. The presence of the payload header is ignored for this purpose, whether the error occurred before the payload header was encountered, while processing the payload header's content, or while processing the remainder of the packet beyond the payload header. If an ICMP Parameter Problem message is to be sent the ``pointer'' value in its header is calculated by taking the offset from the defined header field indicating the particular error being reported from the start of the original IPv6 packet. Any intervening payload header is treated as any other header for this purpose. Payload headers themselves can generate ICMP error packets due to any of the following errors. unrecognised ``next header'' field - processed in the same way as similar errors in other headers, but not until the enclosed payload has been processed. unrecognised ``payload type'' field - processed by returning a Parameter Problem ICMP message, using the usual rules for sending such a message, and with the ``pointer'' set to indicate the ``payload type'' field. The content of the data field of the payload header is ignored, then the rest of the packet is processed as if the payload header were correctly processed. kre [Page 7] Internet Draft draft-kre-ipv6-payload-00.txt March 1995 bad ``length'' field - A Parameter Problem ICMP message is returned, in the normal manner, with the ``pointer'' set to indicate the first octet of the ``length'' field, that is, the most significant bits. Both the enclosed payload data, and the remainder of the original IPv6 packet are ignored. bad ``alignment length'' in APH header - A parameter problem ICMP message is sent in the usual way with the ``pointer'' set to the first (most significant) octet of the alignment field. The payload data is ignored, and the remainder of the packet processed as if the payload had been correctly processed. 14. Scope It is beyond the scope of this memo to define, or even suggest, the circumstances in which the Payload Header should be used. Implementations are free to experiment with using it wherever it seems it might be useful. However, implementations sending Payload Headers should be prepared to adapt to later recommendations published as experience is gained with the use of this header. 15. TMux Comparison The Payload Header is quite similar to the TMux proposal of Cameron, Crocker, Cohen, and Postel [RFC1692]. The standard header format is quite similar, replacing the one byte checksum of TMux with the ``Next Header'' field of the payload header. Header checksums are not frequently used in IPv6, so the lack of the checksum here is in accordance with the general IPv6 spirit. The presence of the ``Next Header'' field makes the format reflect IPv6 standards, and also allows considerably more generality in the use of the packet - eg: it permits a large transport datagram, much larger than either TMux or payload headers are capable of carrying to be appended to a datagram carrying Payload Header(s). The alignment field in the APL also permits any IPv6 packet header, most likely, an authentication or security header, to be carried in the payload data, which the older TMux design does not. The TMux specification gives considerable guidelines as to exactly how and when multiple segments should be grouped into one datagram, which this memo does not attempt to do. The guidance given there may prove useful to implementors of the Payload Header, however at the present time, lack of experience with its use leads to a preference for omitting any specific hints here. kre [Page 8] Internet Draft draft-kre-ipv6-payload-00.txt March 1995 16. References To be supplied, incl 1692, IPv6 spec, IPv6 ICMP spec, etc. 17. Acknowledgements To be supplied. kre [Page 9]