Network Working Group J. Jurski Internet Draft Gdansk University of Technology Document: draft-jurski-pppext-iphc-02.txt March 2007 Expires: September 2007 Category: Informational Limited IP Header Compression over PPP Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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. This Internet-Draft will expire on September, 1 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Jurski Expires - September 2007 [Page 1] Internet-draft Limited IP Header Compression over PPP March 2007 Abstract The negotiation options specified in RFC 2509 defined an all-or-nothing strategy for applying header compression: peers were assumed to support compression for any combination of headers. [RFC3544] refined that strategy to make it possible to negotiate header compression for only TCP or only non-TCP packets (and also added Enhanced RTP-Compression negotiation option). The current document further refines the strategy by also making it possible to negotiate header compression for only particular combinations of headers or header types. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Table of Contents 1. Introduction...................................................3 2. Configuration Suboptions to Disable Particular Header Compression Types..............................................4 2.1 Limitations for Differential TCP Compression..............5 2.2 Limitations for non-differential TCP Compression..........7 2.3 Limitations for non-TCP Compression.......................9 3. Changes from Previous RFCs....................................11 4. Motivation....................................................11 5. References....................................................12 5.1 Normative References.....................................12 5.2 Informative References...................................13 6. IANA Considerations...........................................13 7. Security Considerations.......................................13 Acknowledgments..................................................13 Author's Address.................................................14 Intellectual Property Statement..................................14 Full Copyright Statement.........................................14 Jurski Expires - September 2007 [Page 2] Internet-draft Limited IP Header Compression over PPP March 2007 1. Introduction The IP Header Compression (IPHC) defined in [RFC2507] may be used for compression of both IPv4 and IPv6 datagrams or packets encapsulated with multiple IP headers. IPHC is also capable of compressing both TCP and UDP transport protocol headers. The IP/UDP/RTP header compression defined in [RFC2508] and [RFC3545] fits within the framework defined by IPHC so that it may also be applied to both IPv4 and IPv6 packets. In order to establish compression of IP datagrams sent over a PPP link, each end of the link must agree on a set of configuration parameters for the compression. The process of negotiating link parameters for network layer protocols is handled in PPP by a family of network control protocols (NCPs). Configuration options to be used to negotiate parameters for the compression scheme are described in [RFC3544] (and RFC 2509). According to [RFC3544] and RFC 2509, all combinations of headers are compressed and decompressed. Therefore, it is not possible to disable compression for a particular header type or a combination of headers. For example, even nodes that only support IPv4 had to support IPv6 header compression because it is impossible to specify that IPv6 headers shall not be compressed. This document adds three new suboptions to the IP header compression configuration option defined in [RFC3544] (and RFC 2509). By using these new suboptions, the decompressor can request that the use of compression for particular header types or combinations of headers in the datagram is disabled. For example, a node that only supports IPv4 can request to not receive compressed IPv6 headers (such headers will be sent by the compressor without the use of header compression). These suboptions can also be used by the compressor to tell the decompressor that some header types or header combinations will not be compressed. Jurski Expires - September 2007 [Page 3] Internet-draft Limited IP Header Compression over PPP March 2007 2. Configuration Suboptions to Disable Particular Header Compression Types [RFC3544] in section 2.1 specifies the IPCP IP-Compression-Protocol option and several suboptions for this option. This document adds three new suboptions: type 4, 5, and 6. The new suboptions are added to make it possible for a decompressor to specify which particular types of headers or their combinations MUST NOT be compressed by a compressor. Separate sets of limitations are defined in the following subsections for differential TCP, non- differential TCP, and non-TCP compression methods. NOTE: [RFC1332] is not explicit about whether the negotiation options negotiate the capabilities of the receiver or of the sender. In keeping with current practice, it is assumed that the suboptions describe the capabilities of the decompressor (receiving side), which sends the Configure-Request message. On the other hand, options included in Configure-Nak messages are a suggestion of the compressor (sending side). Note that flag A of suboption 4 and flag B of suboption 5 overlap with suboption 3 with parameter 1 (see section 2.4 in [RFC3544] for the description of suboption 3). For this reason, in order to avoid a suboptimal NCP negotiation exchange, peers SHOULD use suboption 3 with parameter 1 to completely disable TCP compression, instead of setting both flags A and B in suboption 4 and 5. Accordingly, peers implementing suboptions 4 and 5 SHALL also understand suboption 3. NOTE: The compression limitations specified in these suboptions should be used with care. Indiscriminate use of these limitations may lead to suboptimal compression, or even no compression. General purpose systems SHOULD normally request no limitation and use the full compression functionality defined in RFC 2509 or [RFC3544]. The decompressor MAY be configured to request limited compression only when advantages and disadvantages of such a decision are carefully examined, including scenarios when the compressor may not fully support all combinations of flags specified in these suboptions. Although new implementations of the compressor are expected to support these suboptions, there are many older systems that do not support them. The decompressor SHOULD agree on the full RFC 2509 or [RFC3544] compression if it receives a request from an older peer (compressor). Jurski Expires - September 2007 [Page 4] Internet-draft Limited IP Header Compression over PPP March 2007 2.1 Limitations for Differential TCP Compression This suboption, when included in the suboptions field of the configuration option defined in section 2.1 in [RFC3544], defines limitations that apply for the differential encoding compression method only. Description Disable differential TCP header compression for a particular compression method(s), header type(s), or header combination(s). 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length |A B C D E F G| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 4 Length = 4 Flags (ABCDEFG) This field is a set of bit-flags that specify limitations. A flag set refers to a particular limitation: A: TCP differential encoding method shall not be used at all ([RFC2507], Section 7.12.1); if this flag is set, the remaining flags are irrelevant (MUST be set to zero by the sender and ignored by the receiver) B: Unused – MUST be set to zero by the sender and ignored by the receiver C: IPv4 header can be compressed only if it is the first header in the compression chain (i.e. tunneled IPv4 headers are not compressed and break the compression chain of headers); if this flag is set for IPv6 Control Protocol, IPv4 header compression is completely disabled (see Section 3 in [RFC3544] for explanation) D: IPv6 base header can be compressed only if it is the first header in the compression chain (i.e. tunneled IPv6 headers are not compressed and break the compression chain of headers); if this flag is set for IP Control Protocol, IPv6 Jurski Expires - September 2007 [Page 5] Internet-draft Limited IP Header Compression over PPP March 2007 header compression is completely disabled (see Section 3 in [RFC3544] for explanation) E: IPv4 header for a fragment or with options shall not be compressed ([RFC2507], Section 7.13, point b); this flag is irrelevant if IPv4 header compression is completely disabled F: IPv6 extension headers shall not be compressed ([RFC2507], Sections from 7.1 to 7.10); this flag is irrelevant if IPv6 header compression is completely disabled G: minimal encapsulation header shall not be compressed ([RFC2507], Section 7.14) Reserved MUST be set to zero by the sender and ignored by the receiver. This suboption SHOULD NOT be included in an NCP message if suboption 3 with parameter 1 is included (see section 2.4 in [RFC3544] for the description of suboption 3). If this suboption is included multiple times, the sum of all the limitations applies (logical-or on all flags). Jurski Expires - September 2007 [Page 6] Internet-draft Limited IP Header Compression over PPP March 2007 2.2 Limitations for non-differential TCP Compression This suboption, when included in the suboptions field of the configuration option defined in section 2.1 in [RFC3544], defines limitations that apply for the non-differential encoding compression method only. Description Disable non-differential TCP header compression for a particular compression method(s), header type(s), or header combination(s). 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length |A B C D E F G| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 5 Length = 4 Flags (ABCDEFG) This field is a set of bit-flags that specify limitations. A flag set refers to a particular limitation: A: Unused – MUST be set to zero by the sender and ignored by the receiver B: TCP non-differential encoding method shall not be used ([RFC2507], Section 7.12.2); if this flag is set, the remaining flags are irrelevant (MUST be set to zero by the sender and ignored by the receiver) C: IPv4 header can be compressed only if it is the first header in the compression chain (i.e. tunneled IPv4 headers are not compressed and break the compression chain of headers); if this flag is set for IPv6 Control Protocol, IPv4 header compression is completely disabled (see Section 3 in [RFC3544] for explanation) D: IPv6 base header can be compressed only if it is the first header in the compression chain (i.e. tunneled IPv6 headers are not compressed and break the compression chain of headers); if this flag is set for IP Control Protocol, IPv6 Jurski Expires - September 2007 [Page 7] Internet-draft Limited IP Header Compression over PPP March 2007 header compression is completely disabled (see Section 3 in [RFC3544] for explanation) E: IPv4 header for a fragment or with options shall not be compressed ([RFC2507], Section 7.13, point b); this flag is irrelevant if IPv4 header compression is completely disabled F: IPv6 extension headers shall not be compressed ([RFC2507], Sections from 7.1 to 7.10); this flag is irrelevant if IPv6 header compression is completely disabled G: minimal encapsulation header shall not be compressed ([RFC2507], Section 7.14) Reserved MUST be set to zero by the sender and ignored by the receiver. This suboption SHOULD NOT be included in an NCP message if suboption 3 with parameter 1 is included (see section 2.4 in [RFC3544] for the description of suboption 3). If this suboption is included multiple times, the sum of all the limitations applies (logical-or on all flags). Jurski Expires - September 2007 [Page 8] Internet-draft Limited IP Header Compression over PPP March 2007 2.3 Limitations for non-TCP Compression This suboption, when included in the suboptions field of the configuration option defined in section 2.1 in [RFC3544], defines limitations that apply for the non-TCP compression method only. Description Disable non-TCP header compression for a particular compression method(s), header type(s), or header combination(s). 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length |A B C D E F G H I J K| Reserved| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 6 Length = 4 Flags (ABCDEFGHIJK) This field is a set of bit-flags that specify limitations. A flag set refers to a particular limitation: A: Unused – MUST be set to zero by the sender and ignored by the receiver B: Unused – MUST be set to zero by the sender and ignored by the receiver C: IPv4 header can be compressed only if it is the first header in the compression chain (i.e. tunneled IPv4 headers are not compressed and break the compression chain of headers); if this flag is set for IPv6 Control Protocol, IPv4 header compression is completely disabled (see Section 3 in [RFC3544] for explanation) D: IPv6 base header can be compressed only if it is the first header in the compression chain (i.e. tunneled IPv6 headers are not compressed and break the compression chain of headers); if this flag is set for IP Control Protocol, IPv6 header compression is completely disabled (see Section 3 in [RFC3544] for explanation) Jurski Expires - September 2007 [Page 9] Internet-draft Limited IP Header Compression over PPP March 2007 E: IPv4 header for a fragment or with options shall not be compressed ([RFC2507], Section 7.13, point b); this flag is irrelevant if IPv4 header compression is completely disabled F: IPv6 extension headers shall not be compressed ([RFC2507], Sections from 7.1 to 7.10); this flag is irrelevant if IPv6 header compression is completely disabled G: minimal encapsulation header shall not be compressed ([RFC2507], Section 7.14) H: UDP headers with non-zero UDP checksum shall not be compressed ([RFC2507], Section 7.11); note that the checksum cannot be zero with IPv6 I: the compressed chain of headers must include a compressed UDP or a compressed RTP header; if the compressible chain of headers does not include a UDP or RTP header, the whole chain cannot be compressed J: the compressed chain of headers must include a compressed RTP header; if the compressible chain of headers does not include a RTP header, the whole chain cannot be compressed; this flag is irrelevant if flag I is set; this flag MUST be set to zero by the sender and ignored by the receiver if RTP compression is not enabled (with use of suboption 1 or 2 as specified in Section 2.2 or 2.3, respectively) K: RTP headers with non-empty CSRC list shall not be compressed ([RFC2508], Section 3.3.2); this flag MUST be set to zero by the sender and ignored by the receiver if RTP compression is not enabled Reserved MUST be set to zero by the sender and ignored by the receiver. This suboption SHOULD NOT be included in an NCP message if suboption 3 with parameter 2 is included (see section 2.4 in [RFC3544] for the description of suboption 3). If this suboption is included multiple times, the sum of all the limitations applies (logical-or on all flags). Jurski Expires - September 2007 [Page 10] Internet-draft Limited IP Header Compression over PPP March 2007 3. Changes from Previous RFCs This document defines new suboptions for Header Compression negotiation. These suboptions are only an addition to [RFC3544] (and RFC 2509) and the content of [RFC3544] is not obsoleted. The new suboptions defined in this document modify the stopping criteria specified in [RFC2507] in Section 7. This can be considered as adding a new subpoint "c)" to the list in the first paragraph of Section 7 in [RFC2507]. This new subpoint would specify that the compressible chain of headers would be additionally limited by the new suboptions. 4. Motivation It may be desirable to limit the compression mechanisms in specific situations, so that not all types or combinations of headers are compressed and decompressed. Similarly, it may be desirable that the compressor is able to inform the decompressor that some types or combinations of headers will not be compressed. This document makes it possible. Two reasons for using these limitations are listed here as examples: - limited compression method may be useful to control the natural trade-off between compression efficiency and system resource usage (such as link capacity, processing power, and memory) - using the non-differential compression method only may be beneficial when packet re-ordering or high error rate are expected on the link While the compressor could use heuristics to determine the most efficient way to compress flows, the decompressor may be in a much better position to know the expected traffic type, resource limitations, and usage conditions. Since there is no way of making dynamic adjustments in the negotiated values for IPHC protocol, the negotiation suboptions specified in this document may be useful. Proposed extensions make the protocol more flexible and suitable in more various usage scenarios, so they may also be beneficial for other reasons. For example, with a predefined amount of memory, one can provide a limited compression to 1000 users instead of supporting full compression for only 500 users. However, a request for these new suboptions might also cause inefficient use of the available link capacity. Especially because many compressors do not support these new suboptions and may not support them in the future. Therefore, the decompressor shall Jurski Expires - September 2007 [Page 11] Internet-draft Limited IP Header Compression over PPP March 2007 request limited compression with care. And for this reason, the new suboptions are designed backward-compatible, so that peers that do not support the new suboptions can interoperate with peers that support them by using the full functionality defined in RFC 2509 or [RFC3544]. The best solution for general purpose equipment, such as Internet routers, is compression with no limitations. 5. References 5.1 Normative References [RFC1144] Jacobson, V., "Compressing TCP/IP Headers for low-speed serial links", RFC 1144, February 1990. [RFC1332] McGregor, G., "The PPP Internet Protocol Control Protocol (IPCP)", RFC 1332, May 1992. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2472] Haskin, D. and E. Allen, "IP Version 6 over PPP", RFC 2472, December 1998. [RFC2507] Degermark, M., Nordgren, B. and S. Pink, "Header Compression for IP", RFC 2507, February 1999. [RFC2508] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP Headers for Low-Speed Serial Links", RFC 2508, February 1999. [RFC3241] Bormann, C., "Robust Header Compression (ROHC) over PPP", RFC 3241, April 2002. [RFC3544] Koren, T., Casner, S., Bormann, C., "IP Header Compression over PPP", RFC 3544, July 2003. [RFC3545] Koren, T., Casner, S., Geevarghese, J., Thompson, B. and P. Ruddy, "Enhanced Compressed RTP (CRTP) for Links with High Delay, Packet Loss and Reordering", RFC 3545, July 2003. Jurski Expires - September 2007 [Page 12] Internet-draft Limited IP Header Compression over PPP March 2007 5.2 Informative References [RFC1661] Simpson, W., Ed., "The Point-To-Point Protocol (PPP)", STD 51, RFC 1661, July 1994. [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [RFC2686] Bormann, C., "The Multi-Class Extension to Multi-Link PPP", RFC 2686, September 1999. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC 3550, July 2003. 6. IANA Considerations Three new assignments in existing IANA registry titled "IP Header Compression Configuration Option Suboption Types" are needed for the suboption types defined in this document. 7. Security Considerations Negotiation of the suboptions defined here imposes no additional security considerations beyond those that otherwise apply to PPP [RFC1661]. Acknowledgments The author would like to thank particularly to Piotr Uminski for his contribution to this document and to James Carlson, Carsten Bormann, and Stephen L. Casner for their critical comments regarding the new suboptions. Mathias Engan, Stephen L. Casner, Carsten Bormann, and Tmima Koren are the authors of RFC 2509 and [RFC3544] documents, on which this document is based. Jurski Expires - September 2007 [Page 13] Internet-draft Limited IP Header Compression over PPP March 2007 Author's Address Janusz Jurski Gdansk University of Technology ul. Narutowicza 11/12 80-952 Gdansk Poland Email: jjurski@eti.pg.gda.pl Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the ISOC's procedures with respect to rights in ISOC Documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. Jurski Expires - September 2007 [Page 14]