Internet Engineering Task Force Francis Dupont INTERNET DRAFT ENST Bretagne Expires in August 2002 March 2002 The IPv6 Payload Header Status of this Memo This document is an Internet Draft and is in full conformance with all provisions of Section 10 of RFC 2026. 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." The list of current Internet Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Distribution of this memo is unlimited. Abstract This draft describes a method by which many IPv6 payload data bodies may be encapsulated in a single IPv6 datagram using a new non-terminal header will contain both a payload and necessary fields (like a ``next header'' field) allowing header chaining. This document specifies how two packets can be merged into a single one and the reverse one-step operation. But the main purpose is to provide a basis to discussions about the pros and cons of such a mechanism (note: this was done). draft-dupont-ipv6-payload-01.txt [Page 1] INTERNET-DRAFT IPv6 payload header Mar 2002 1. Introduction The IPv6 [1] packet structure is a chain of any number of non-terminal headers ending by a terminal ``upper-layer'' header with the payload. By definition there is one and only one terminal header per packet. This memo proposes a mechanism which removes this limitation, and collects the pros and cons of such a mechanism. 2. Changes From Previous Draft The mechanism itself was moved to an annex because there was a strong consensus against it at the 52th IETF meeting at Salt Lake City when it was presented at the IPv6 working group session. The relevant part of the proceeding is available in a second annex. 3. Discussion (Introduction From Previous Draft) Even specialized similar mechanisms (like piggy-backing of Binding Updates in IPv6 mobility [10]) are known to interfere with other mechanisms as path MTU discovery [2], IPsec [3] selector in SPD or RObust Header Compression [4]. If the path MTU is known per destination, a good implementation should reduce the impact of the payload header. For instance, no too large packets should be sent. The IPsec SPD selector problem is harder because it cannot really work with non-terminal headers. Outside of this untractable case, the split procedure will give individual packets to the Security Policy Database check with clear upper-layer possible selectors. ROHC issue seems even harder but if the payload header mechanism is proved to have bad interactions with (another) header compression one, the split procedure can remove its visible effects including bad effects. One can believe with a split procedure or a similar predefined procedure the payload header class of mechanisms has only advantages as soon as they are widely supported but things are not so simple. There are two main reasons to use this kind of mechanisms: efficiency and atomicity. draft-dupont-ipv6-payload-01.txt [Page 2] INTERNET-DRAFT IPv6 payload header Mar 2002 Efficiency because this reduces the number of bytes sent over the Internet (poor argument) and because this reduces the number of packets sent over some links with a medium which has a notable acquisition delay. This is a good argument but a link dedicated mechanism is do a better job. For this problem a solution in the IETF scope should be a compatible with or part of ROHC device which mainly reduces the number of frames. The atomicity idea is very different: if two control messages are strongly related, for instance a Binding Update and a RSVP QoS negotiation, one can want to get them together in the same smaller packet. 11. Security and IANA Considerations Not yet! 12. Acknowledgments The last document [11] about an IPv6 payload header was presented by Robert Elz in 1995. In a long and warm discussion about the piggy-backing feature of Mobile IPv6 in the mobile-ip WG list, some of them, including Eric Nordmark, proposed to reopen the general idea in order to get an argumented discussion in the proper place, i.e. the IPv6 WG (aka IPngWG) of the Internet area. The previous version of the draft was presented and received a not rough at all consensus against it (so it was in fact very successful). It was decided to produce a second version in order to properly kill this bad idea. 13. Normative References [1] S. Deering, R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [2] J. McCann, S. Deering, J. Mogul, "Path MTU Discovery for IP version 6", RFC 1981, August 1996. [3] S. Kent, R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998. [4] C. Bormann & all, "RObust Header Compression (ROHC): ...", RFC 3095, July 2001. draft-dupont-ipv6-payload-01.txt [Page 3] INTERNET-DRAFT IPv6 payload header Mar 2002 [5] D. Borman, S. Deering, R. Hinden, "IPv6 Jumbograms", RFC 2675, August 1999. [6] S. Kent, R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998. [7] A. Shacham, R. Monsour, R. Pereira, M. Thomas, "IP Payload Compression Protocol (IPComp)", RFC 3173, September 2001. [8] K. Ramakrishnan, S. Floyd, D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001. [9] A. Conta, S. Deering, "Internet Control Message Protocol (ICMPv6) ... Specification", RFC 2463, December 1998. 14. Informative References [10] D. Johnson, C. Perkins, "Mobility Support in IPv6", draft-ietf-mobileip-ipv6-15.txt, July 2001. [11] R. Elz, "The IPv6 Payload Header", draft-kre-ipv6-payload-01.txt, October 1995. [12] F. Dupont, "IPv6 destination option header clarification", draft-dupont-destoptupd-01.txt, November 2001. 15. Author's Address Francis Dupont ENST Bretagne Campus de Rennes 2, rue de la Chataigneraie BP 78 35512 Cesson-Sevigne Cedex FRANCE Fax: +33 2 99 12 70 30 EMail: Francis.Dupont@enst-bretagne.fr draft-dupont-ipv6-payload-01.txt [Page 4] INTERNET-DRAFT IPv6 payload header Mar 2002 ANNEX I. The IPv6 Payload Header I.1. New Header A new IPv6 header is proposed to implement the functionality. All IPv6 nodes must be able to receive and process this header correctly, though nodes need not send them if the functionality is not required. The header is a non-terminal [12] one, i.e. it contains a next header field to allow chaining to further IPv6 headers, often, though without being required, more of this new header. The header is followed 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 header also contains a Header Length field, giving the length of the header, an Internal Next Header type field, giving the IP protocol number of the (first) enclosed header, a Pad Length field, giving the length of the trailing padding in octets, and a Data Info field, giving optionally the first four octets of the original packet containing the data, i.e. the original version, traffic class and flow label. I.2. Layout 0 7 8 15 16 23 24 31 ----------------------------------------------------------------- | | | | | | Next Header | Header Length | Int Nxt Hdr | Pad Length | | | | | | ----------------------------------------------------------------- | | | Data Info | | | ----------------------------------------------------------------- | | | Data (8 * Length octets) ... | | | | /------------------------------------| | / Trailing Padding | -------------------------/--------------------------------------- I.3. Header Values The IPv6 payload header type is to be defined by the IANA. For testing purpose only the value 144 can be temporary used. draft-dupont-ipv6-payload-01.txt [Page 5] INTERNET-DRAFT IPv6 payload header Mar 2002 I.4. Header Fields The IPv6 payload header contains fields with the following meanings. I.4.1. Next Header This 8 bit field contains the protocol type of the header that follows the Payload Header and associated data. Its value is taken from the list of IP protocol types regularly published by the IANA. I.4.2. Header Length This 8 bit unsigned integer field contains the length of the whole payload header in 8 octet units, not including the first 8 octets. BTW this is the length of the data field including the trailing padding. This limits the possible length of the payload to 2040 octets, this is not considered as an issue. I.4.3. Internal Next Header 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. I.4.4. Pad Length This 8 bit unsigned integer field contains the number of padding octets that have to be appended to the Data field in order to make the whole length a multiple of 8 in octets as described in the next subsection. I.4.5. Data The first octet of this field is also the first octet of a header of the type defined by the ``Internal Next Header'' field and is aligned on a 8 octet boundary. If the length of this field 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 in octets. At most 7, and of course, no less than 0, such additional octets are added. draft-dupont-ipv6-payload-01.txt [Page 6] INTERNET-DRAFT IPv6 payload header Mar 2002 I.5. Use of the Payload Header 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. This limitation applies to any case where intended en route processing should be different between two packets to merge, even if a logical split operation can be applied in order to recover hidden differences. For the same kind of reasons, the payload header should be used end-to-end. The last limitation avoids a too complex case in the following procedures: no non-terminal header which contains a packet length field (i.e. another IP header or a jumbogram [5] option) or which can hide a next header or a header length field (i.e. ESP [6] or IPComp [7]) should be considered for sharing. I.6. Merging Procedure (One Step) If two small enough packets are to be send to the same destination still in a sending queue, or an upper-layer service element is to be sent with the next packet or on timeout (piggy-backing situation [10]), a merging operation can be applied. The benefits are: - a packet with smaller length than the sum of the lengths of the two packets (from sharing). - one packet in place of two packets (for instance when the medium acquisition delay is large compared to the time to transmit many bits). draft-dupont-ipv6-payload-01.txt [Page 7] INTERNET-DRAFT IPv6 payload header Mar 2002 Of course this operation can be repeated in order to merge more than two packets but if possible the order should be kept and merging should be linear (i.e. payload headers should be chained, not included into themselves). In the uncommon case where the IPv6 header payload length is smaller than it should be the packet should be trimmed (i.e. extra octets removed). The two packets must be scanned in order to verify if the two packets can be merged (i.e. if there is no exception listed in the previous section or if the resulting packet will be too large or the payload header not large enough) and if non-terminal header chains are identical i.e. can/will be shared. So each packet begins by a shared part followed by a not-shared part which includes the terminal stuff. The not-shared part of the second packet is put a new IPv6 payload header with in the internal next header field the type of the first not-shared header (which can be found in the next header field of the last shared header). Padding is appended if needed and its length is put in the pad length field. If the first four octets of the (second) packet are different from the first packet then they should be saved in the data info field else the data info field must be set to zero. Then the IPv6 payload header must be inserted into the first packet header chain between the shared and the not-shared parts, i.e. the next header field of the last shared header is copied in the IPv6 payload header and set to the type of the payload header, and the IPv6 header payload length adjusted according to the IPv6 payload header length in octets (i.e. 8 + 8 * Header Length). The merged packet should replace in the sending queue the first (to be sent) packet. The idea is to try to merge a new packet with waiting to be sent packets to the same destination when the new packet will be added in the queue. I.7. Split Procedure (One Step) The split procedure must be applied by the receiving end node but is provided as a logical operation to intermediate routers which need to look at/into further inside packets (in order to make individual packet mechanisms still available). draft-dupont-ipv6-payload-01.txt [Page 8] INTERNET-DRAFT IPv6 payload header Mar 2002 This description assumes that there is a reception queue where incoming packets are put in order waiting for processing. When the header processing encounters a payload header, the already processed part (the shared part) is duplicated and the further processing is divided into two phases. The first phase builds a packet with a copy of the already processed part and the data field of the payload header, if the data info field is not zero then it is copied into the first four octets of the IPv6 header, the internal next header is copied to the next header field of the last processed header (which should have contained the type of the IPv6 payload header) and the IPv6 header length must be set (to the sum of the length of the data field and of the length of the already processed part not including the IPv6 header). If the traffic class or the flow label is restored when an en route processing should have changed it (ECN [8] Congestion Experienced set) the en route processing should be simulated. Then the rebuilt packet should be put in the front (i.e. to be processed next) of the reception queue. After the phase two the packet processing should be immediately resumed after the last already processed header. If there are more than one payload header the merge procedure puts recent packets before olders and the stack structure of the queue will restore the original order. The phase two removes the payload header from the packet, leaving the (original) already processed and the remaining parts. The chain must be restored, i.e. the next header field of the payload header must be copied into the next header field of the last processed header (same remark than for phase one). The IPv6 header payload length must be adjusted according to the IPv6 payload header length in octets. Then the next header (which has its type into the last processed header) must be processed, i.e. (header) processing resumes after the last already processed header. draft-dupont-ipv6-payload-01.txt [Page 9] INTERNET-DRAFT IPv6 payload header Mar 2002 I.8. Semantics A packet containing a payload header shall be semantically equivalent to two packets, received in the reversed order that they are present in the combined packet - that is, the body of the payload second, and the rest of the packet first, 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. If it should become necessary to send an ICMP [9] error packet in response to a received packet containing a payload header: - if the error is detected before the payload header processing (aka the split procedure), the returned packet contents shall be the original IPv6 packet (or as much of it as will fit). - if the error is detected during the payload header processing, the returned packet contents must be the original IPv6 packet (same remark). Possible errors are unrecognized ``next header'' or ``internal next header'', bad ``header length'' or ``pad length''. - if the error is detected after the payload header processing, the returned packet contents shall be the a packet produced by this processing or the original one. The ICMP error packet reception processing should support returned packets with a payload header, i.e. should be able to apply the split procedure on it with the proper computation of the ``pointer'' value. draft-dupont-ipv6-payload-01.txt [Page 10] INTERNET-DRAFT IPv6 payload header Mar 2002 ANNEX II. The 52th IETF Proceeding The IPv6 Payload Header, Francis Dupont ---------------------------------------- Presented the idea and its origin: old draft by Robert Elz, and piggy-backing discussion in the mobile-ip mailing-list Pros & Cons: + reduce the number of delays for medium acquisition + the "atomicity" argument: if a binding update and a RSVP renegotiation are in the same packet they should be processed in the same time. - this is a link-layer issue Wants feed back from w.g. Good idea, bad idea, etc. Steve Deering: This approach was proposed before and the w.g. choose to not adopt it. The issue comes up when where media access cost is high. If this is motivation, best to handle at level 2, not at IP layer. Francis Dupont: Agrees, not in favor of his own proposal! Brian Carpenter: This will break boxes that look inside of packets like firewalls, etc. Erik Nordmark: Some folks in Mobile IPv6 don't like L2 piggy backing. L2 approach doesn't help with outgoing traffic. Might be useful in some environments or some specific cases. Useful to explore. People who want to use this will need to deal with the issues. Hesham Soliman: Dangerous to combine things that are not related to each other in same packet. They might need different QOS, special handling, etc. Strong consensus to not continue this work. Francis Dupont will write draft that discusses pros and cons and show why this should not be done. draft-dupont-ipv6-payload-01.txt [Page 11]