Skip to main content

RObust Header Compression (ROHC): A Profile for TCP/IP (ROHC-TCP)
RFC 4996

Revision differences

Document history

Date Rev. By Action
2020-01-21
16 (System) Received changes through RFC Editor sync (added Verified Errata tag)
2018-12-20
16 (System)
Received changes through RFC Editor sync (changed abstract to 'This document specifies a ROHC (Robust Header Compression) profile for compression of TCP/IP packets. The profile, …
Received changes through RFC Editor sync (changed abstract to 'This document specifies a ROHC (Robust Header Compression) profile for compression of TCP/IP packets. The profile, called ROHC-TCP, provides efficient and robust compression of TCP headers, including frequently used TCP options such as SACK (Selective Acknowledgments) and Timestamps.

ROHC-TCP works well when used over links with significant error rates and long round-trip times. For many bandwidth-limited links where header compression is essential, such characteristics are common. [STANDARDS-TRACK]')
2017-05-16
16 (System) Changed document authors from "Kristofer Sandlund, Mark West, Ghyslain Pelletier" to "Kristofer Sandlund, Mark West, Ghyslain Pelletier, Lars-Erik Jonsson"
2015-10-14
16 (System) Notify list changed from rohc-chairs@ietf.org,ghyslain.pelletier@ericsson.com,kristofer.sandlund@ericsson.com,mark.a.west@roke.co.uk to (None)
2007-07-31
16 Amy Vezza State Changes to RFC Published from RFC Ed Queue by Amy Vezza
2007-07-31
16 Amy Vezza [Note]: 'RFC 4996' added by Amy Vezza
2007-07-30
16 (System) RFC published
2007-04-02
16 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2007-04-02
16 (System) IANA Action state changed to Waiting on RFC Editor from In Progress
2007-04-02
16 (System) IANA Action state changed to In Progress from Waiting on Authors
2007-03-29
16 (System) IANA Action state changed to Waiting on Authors from In Progress
2007-03-19
16 (System) IANA Action state changed to In Progress
2007-03-16
16 Amy Vezza State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza
2007-03-15
16 Amy Vezza IESG state changed to Approved-announcement sent
2007-03-15
16 Amy Vezza IESG has approved the document
2007-03-15
16 Amy Vezza Closed "Approve" ballot
2007-03-12
16 Magnus Westerlund State Changes to Approved-announcement to be sent from Approved-announcement to be sent::Point Raised - writeup needed by Magnus Westerlund
2007-03-12
16 Magnus Westerlund RFC-editor note added and ready for approval
2007-03-09
16 (System) Removed from agenda for telechat - 2007-03-08
2007-03-08
16 Amy Vezza State Changes to Approved-announcement to be sent::Point Raised - writeup needed from IESG Evaluation by Amy Vezza
2007-03-08
16 (System) [Ballot Position Update] New position, No Objection, has been recorded for Sam Hartman by IESG Secretary
2007-03-08
16 Mark Townsley [Ballot Position Update] New position, No Objection, has been recorded by Mark Townsley
2007-03-08
16 Jon Peterson [Ballot Position Update] New position, No Objection, has been recorded by Jon Peterson
2007-03-08
16 Jari Arkko [Ballot Position Update] New position, No Objection, has been recorded by Jari Arkko
2007-03-08
16 Bill Fenner [Ballot Position Update] New position, No Objection, has been recorded by Bill Fenner
2007-03-07
16 Ross Callon [Ballot Position Update] New position, No Objection, has been recorded by Ross Callon
2007-03-07
16 Cullen Jennings [Ballot Position Update] New position, No Objection, has been recorded by Cullen Jennings
2007-03-07
16 David Kessens [Ballot Position Update] New position, No Objection, has been recorded by David Kessens
2007-03-07
16 Dan Romascanu [Ballot Position Update] New position, No Objection, has been recorded by Dan Romascanu
2007-03-07
16 Magnus Westerlund State Change Notice email list have been change to rohc-chairs@tools.ietf.org,ghyslain.pelletier@ericsson.com,kristofer.sandlund@ericsson.com,mark.a.west@roke.co.uk from rohc-chairs@tools.ietf.org,ghyslain.pelletier@ericsson.com,kristofer.sandlund@ericsson.com
2007-03-07
16 Magnus Westerlund State Change Notice email list have been change to rohc-chairs@tools.ietf.org,ghyslain.pelletier@ericsson.com,kristofer.sandlund@ericsson.com from rohc-chairs@tools.ietf.org,ghyslain.pelletier@ericsson.com
2007-03-07
16 Magnus Westerlund State Change Notice email list have been change to rohc-chairs@tools.ietf.org,ghyslain.pelletier@ericsson.com from rohc-chairs@tools.ietf.org
2007-03-06
16 Ted Hardie [Ballot Position Update] New position, No Objection, has been recorded by Ted Hardie
2007-03-06
16 Ted Hardie
[Ballot comment]
While I think the description of what to do when ECN is present is probably sufficiently clear to
get the correct implementation, I …
[Ballot comment]
While I think the description of what to do when ECN is present is probably sufficiently clear to
get the correct implementation, I did not understand the design rational as presented.  The
document says:

6.1.3.  Explicit Congestion Notification (ECN)

  When ECN [RFC3168] is used once on a flow, the ECN bits could change
  quite often.  ROHC-TCP maintains a control field in the context to
  indicate if ECN is used or not.  This control field is transmitted in
  the dynamic chain of the TCP header, and its value can be updated
  using specific compressed headers carrying a 7-bit CRC.

  When this control field indicates that ECN is being used, items of IP
  and TCP headers in the irregular chain include bits used for ECN.  To
  preserve octet-alignment, all of the TCP reserved bits are
  transmitted and, for outer IP headers, the entire TOS/TC field is
  included in the irregular chain.

  The design rationale behind this is the possible use of the "full-
  functionality option" of section 9.1 of [RFC3168].

Section 9.1 of RFC 3168 discusses how ECN interacts with IP tunnels.  The
two different behaviors are described there as: 

  The result is that there are two viable options for the behavior of
  ECN-capable connections over an IP tunnel, including IPsec tunnels:

      * A limited-functionality option in which ECN is preserved in the
        inner header, but disabled in the outer header.  The only
        mechanism available for signaling congestion occurring within
        the tunnel in this case is dropped packets.

      * A full-functionality option that supports ECN in both the inner
        and outer headers, and propagates congestion warnings from nodes
        within the tunnel to endpoints.:

Does the author intend to make a parallel here between ROHC and IP
tunnels, or is there an aspect of the design rational that needs further
discussion?
2007-03-05
16 Brian Carpenter [Ballot comment]
From Gen-ART review by Miguel Garcia:

There's a reference to RFC 2001, which has been obsoleted by RFC 2581.
2007-03-05
16 Brian Carpenter [Ballot Position Update] New position, No Objection, has been recorded by Brian Carpenter
2007-03-04
16 Russ Housley [Ballot Position Update] New position, No Objection, has been recorded by Russ Housley
2007-03-02
16 Lars Eggert [Ballot Position Update] New position, No Objection, has been recorded by Lars Eggert
2007-03-02
16 Samuel Weiler Request for Last Call review by SECDIR Completed. Reviewer: Patrick Cain.
2007-03-01
16 Yoshiko Fong
IANA Last Call Comments:

Action #1:
Upon approval of this document, the IANA will make the
following assignments in the "RObust Header Compression
(ROHC) Profile …
IANA Last Call Comments:

Action #1:
Upon approval of this document, the IANA will make the
following assignments in the "RObust Header Compression
(ROHC) Profile Identifiers "

registry located at http://www.iana.org/assignments/rohc-pro-ids

0x00006 ROHC TCP []
0xnnn06 Reserved []

We understand the above to be the only IANA Action for
this document.
2007-02-20
16 Magnus Westerlund Only Last call comments was a reference to an obsolete RFC (RFC 2001) which has been entered as an RFC-note.
2007-02-20
16 Magnus Westerlund Placed on agenda for telechat - 2007-03-08 by Magnus Westerlund
2007-02-20
16 Magnus Westerlund [Ballot Position Update] New position, Yes, has been recorded for Magnus Westerlund
2007-02-20
16 Magnus Westerlund Ballot has been issued by Magnus Westerlund
2007-02-20
16 Magnus Westerlund Created "Approve" ballot
2007-02-20
16 Magnus Westerlund State Changes to IESG Evaluation from Waiting for AD Go-Ahead by Magnus Westerlund
2007-02-19
16 (System) State has been changed to Waiting for AD Go-Ahead from In Last Call by system
2007-02-13
16 Samuel Weiler Request for Last Call review by SECDIR is assigned to Patrick Cain
2007-02-13
16 Samuel Weiler Request for Last Call review by SECDIR is assigned to Patrick Cain
2007-02-05
16 Amy Vezza Last call sent
2007-02-05
16 Amy Vezza State Changes to In Last Call from Last Call Requested by Amy Vezza
2007-02-05
16 Magnus Westerlund State Changes to Last Call Requested from AD Evaluation::AD Followup by Magnus Westerlund
2007-02-05
16 Magnus Westerlund Last Call was requested by Magnus Westerlund
2007-02-05
16 (System) Ballot writeup text was added
2007-02-05
16 (System) Last call text was added
2007-02-05
16 (System) Ballot approval text was added
2007-02-02
16 (System) Sub state has been changed to AD Follow up from New Id Needed
2007-02-02
16 (System) New version available: draft-ietf-rohc-tcp-16.txt
2007-01-26
16 Magnus Westerlund State Changes to AD Evaluation::Revised ID Needed from AD Evaluation by Magnus Westerlund
2007-01-26
16 Magnus Westerlund AD evaluation comments sent to WG.
2006-12-11
15 (System) New version available: draft-ietf-rohc-tcp-15.txt
2006-12-08
16 Magnus Westerlund State Changes to AD Evaluation from Publication Requested by Magnus Westerlund
2006-11-28
16 Dinara Suleymanova
PROTO Write-up

(1.a)  Who is the Document Shepherd for this document?  Has the
      Document Shepherd personally reviewed this version of the
  …
PROTO Write-up

(1.a)  Who is the Document Shepherd for this document?  Has the
      Document Shepherd personally reviewed this version of the
      document and, in particular, does he or she believe this
      version is ready for forwarding to the IESG for publication?

I (Lars-Erik Jonsson) am the Document Sheperd for this document,
and I have personally reviewed this version of the document, which
I believe is ready for publication.

(1.b)  Has the document had adequate review both from key WG members
      and from key non-WG members?  Does the Document Shepherd have
      any concerns about the depth or breadth of the reviews that
      have been performed?

The document has been reviewed by both key WG members and by key non-
WG members, and I am confident with the depth and breadth of the
reviews.

(1.c)  Does the Document Shepherd have concerns that the document
      needs more review from a particular or broader perspective,
      e.g., security, operational complexity, someone familiar with
      AAA, internationalization or XML?

No concerns!

(1.d)  Does the Document Shepherd have any specific concerns or
      issues with this document that the Responsible Area Director
      and/or the IESG should be aware of?  For example, perhaps he
      or she is uncomfortable with certain parts of the document, or
      has concerns whether there really is a need for it.  In any
      event, if the WG has discussed those issues and has indicated
      that it still wishes to advance the document, detail those
      concerns here.

No concerns!

(1.e)  How solid is the WG consensus behind this document?  Does it
      represent the strong concurrence of a few individuals, with
      others being silent, or does the WG as a whole understand and
      agree with it?

There is strong consensus behind this document within the ROHC WG.

(1.f)  Has anyone threatened an appeal or otherwise indicated extreme
      discontent?

No!

(1.g)  Has the Document Shepherd personally verified that the
      document satisfies all ID nits?  (See
      http://www.ietf.org/ID-Checklist.html and
      http://tools.ietf.org/tools/idnits/).  Boilerplate checks are
      not enough; this check needs to be thorough.  Has the document
      met all formal review criteria it needs to, such as the MIB
      Doctor, media type and URI type reviews?

I have reviewed the document, and believe it satisfies all criterias.

(1.h)  Has the document split its references into normative and
      informative?  Are there normative references to documents that
      are not ready for advancement or are otherwise in an unclear
      state?  If such normative references exist, what is the
      strategy for their completion?  Are there normative references
      that are downward references, as described in [RFC3967]?  If
      so, list these downward references to support the Area
      Director in the Last Call procedure for them [RFC3967].

References are split into normative/informative. There is a pending
normative reference to the ROHC Framework, which has just passed IETF
last-call. There is also a pending normative reference to a companion
document, the ROHC Formal Notation, which is submitted along with
this document.

(1.i)  Has the Document Shepherd verified that the document IANA
      consideration section exists and is consistent with the body
      of the document?  If the document specifies protocol
      extensions, are reservations requested in appropriate IANA
      registries?  Are the IANA registries clearly identified?  If
      the document creates a new registry, does it define the
      proposed initial contents of the registry and an allocation
      procedure for future registrations?  Does it suggested a
      reasonable name for the new registry?  See
      [I-D.narten-iana-considerations-rfc2434bis].  If the document
      describes an Expert Review process has Shepherd conferred with
      the Responsible Area Director so that the IESG can appoint the
      needed Expert during the IESG Evaluation?

The document has an appropriate IANA section, requesting registration
of a ROHC profile identifier for the profile it specifies.

(1.j)  Has the Document Shepherd verified that sections of the
      document that are written in a formal language, such as XML
      code, BNF rules, MIB definitions, etc., validate correctly in
      an automated checker?

Reviewers have confirmed the correctness of the formal specifications.

(1.k)  The IESG approval announcement includes a Document
      Announcement Write-Up.  Please provide such a Document
      Announcement Writeup? 



Technical Summary

  This document specifies a ROHC (RObust Header Compression) profile
  for compression of TCP/IP packets. The profile, called ROHC-TCP,
  provides efficient and robust compression of TCP headers, including
  frequently used TCP options such as SACK (Selective Acknowledgments)
  and Timestamps. ROHC-TCP works well when used over links with
  significant error rates and long round-trip times. For many
  bandwidth-limited links where header compression is essential, such
  characteristics are common.

Working Group Summary

  This document has been in the workings for several years. It first
  appeared as an official WG draft in January 2002, and has since then
  changed shape a couple of times. It has now been rather stable for a
  long time, it has been carefully reviewed by both the WG and
  externals, and there is WG consensus that the document should now be
  published as an RFC.

Document Quality

  The document has been both manually reviewed by several parties with
  different perspectives, and checked by automated tools. During WGLC,
  the document was reviewed by the committed WG reviewers Joe Touch
  and Ted Faber, as well as by Sally Floyd, who provided a review at
  the request of the Transport Area Directorate.
 
Personnel
       
  Document Sheperd for this document is Lars-Erik Jonsson, and Magnus
  Westerlund is the Responsible Area Director.
2006-11-28
16 Dinara Suleymanova Draft Added by Dinara Suleymanova in state Publication Requested
2006-11-26
14 (System) New version available: draft-ietf-rohc-tcp-14.txt
2006-10-06
13 (System) New version available: draft-ietf-rohc-tcp-13.txt
2006-06-22
12 (System) New version available: draft-ietf-rohc-tcp-12.txt
2006-01-04
11 (System) New version available: draft-ietf-rohc-tcp-11.txt
2005-07-01
10 (System) New version available: draft-ietf-rohc-tcp-10.txt
2005-02-23
09 (System) New version available: draft-ietf-rohc-tcp-09.txt
2004-10-27
08 (System) New version available: draft-ietf-rohc-tcp-08.txt
2004-07-20
07 (System) New version available: draft-ietf-rohc-tcp-07.txt
2004-04-02
06 (System) New version available: draft-ietf-rohc-tcp-06.txt
2003-10-28
05 (System) New version available: draft-ietf-rohc-tcp-05.txt
2003-05-23
04 (System) New version available: draft-ietf-rohc-tcp-04.txt
2002-11-06
03 (System) New version available: draft-ietf-rohc-tcp-03.txt
2002-07-05
02 (System) New version available: draft-ietf-rohc-tcp-02.txt
2002-03-26
01 (System) New version available: draft-ietf-rohc-tcp-01.txt
2002-01-31
00 (System) New version available: draft-ietf-rohc-tcp-00.txt