RObust Header Compression (ROHC): A Compression Profile for IP
RFC 3843

Agreed this was valid, reasonable - asked for final check from WG,
and gave a look to the IESG, pointing out that the doc had had no
IESG Discusses, so this could not be touching a previous problem
area.

> From: "Lars-Erik Jonsson (LU/EAB)"  erik.jonsson@ericsson.com>
> To: "'mankin@bell-labs.com'"
> Cc: "'Carsten Bormann (E-mail)'"
> Subject: FW: [rohc] Limiting the number of IP header in IP-
> only profile
> Date: Mon, 24 May 2004 16:56:04 +0200
> -------
>
>
> Allison,
>
> The ROHC IP profile was approved early this year and is currently in
> the IANA queue for profile number assignment. The profile has been
> implemented and early interop testing of
> real-world implementations
> has unfortunately exposed a weakness that we were not
> able to notice
> with experimental implementations, which might make memory management
> very troublesome. The problem is specific to the IP profile, and
> we believe it should be addressed as soon as possible.
>
> Apart from discussions between the implementers, we've had
> discussions on the mail list and there seem to be consensus among
> those who have previously contributed to or reviewed this work to
> fix the problem. Below, you can find the change proposal we have
> produced, which has been acked by the "committed document reviewers"
> of the IP profile.
>
> My question is now, would it be possible to get this in before the
> RFC is published, i.e. can we get your permission to send this as
> a change request to the RFC editor (now or in AUTH 48)? When this
> first was brought up, I said no as I do not like making changes at
> this stage of the publication process, but I have been convinced
> the problem is important enough to try to address.
>
> Please let us know how to proceed.
>
> Thanks!
> /Lars-Erik
>
>
> -----Original Message-----
> From: Lars-Erik Jonsson (LU/EAB)
> Sent: den 11 maj 2004 14:47
> To: Lars-Erik Jonsson (LU/EAB); 'Kristofer Sandlund'; rohc@ietf.org
> Subject: RE: [rohc] Limiting the number of IP header in IP-only profile
>
>
> Me and Kristofer have discussed this issue further and come up with
> a change proposal. Please let us know what you think, both about the
> technical issue/resolution as well as how we should move on with it.
> Kristofer has convinced me that this is important for real-world
> implementations, so our take on it is that we should try to get this
> into the IP profile before publication, if at all possible.
>
> BR
> /L-E
>
>
> ***** CHANGE PROPOSAL FOR THE IP PROFILE *****
>
>
> OLD:
> 3.1.  Static Chain Termination
>    One difference for IP-only compression, compared to IP/UDP
>    compression, is related to the termination of the static chain in IR
>    headers. For the UDP profile, the chain always ends with a UDP header
>    part, which per definition provides the boundaries for the chain. The
>    UDP header is also the last header in the uncompressed packet (except
>    for a potential application header). For the IP-only profile, there
>    is no single last header that per profile definition terminates the
>    chain. Instead, the static chain is terminated if the "Next Header /
>    Protocol" field of a static IP header part indicates anything but IP
>    (IPinIP or IPv6).
>
> NEW:
> 3.1.  Static Chain Termination
>    One difference for IP-only compression, compared to IP/UDP
>    compression, is related to the termination of the static chain in IR
>    headers. For the UDP profile, the chain always ends with a UDP header
>    part, which per definition provides the boundaries for the chain. The
>    UDP header is also the last header in the uncompressed packet (except
>    for a potential application header). For the IP-only profile, there
>    is no single last header that per profile definition terminates the
>    chain. Instead, the static chain is terminated if the "Next Header /
>    Protocol" field of a static IP header part indicates anything but IP
>    (IPinIP or IPv6). Alternatively, the compressor can choose to end the
>    static chain at any IP header, and indicate this by setting the MSB
>    of the IP version field to 1 (0xC for IPv4 or 0xE for IPv6). The
>    decompressor must store this indication in the context for correct
>    decompression of subsequent headers. Note that the IP version field
>    in decompressed headers must be restored to its original value.
>
>
> OLD (part of 3.2):
>    As explained above, the static chain within IR packets can be of
>    arbitrary length, and the chain is terminated by the presence of a
>    As explained above, the static chain within IR packets can be of
>    arbitrary length, and the chain is terminated by the presence of a
>    non-IP header (not IPinIP nor IPv6). The dynamic chain is structured
>    analogously.
>
> NEW (part of 3.2):
>    As explained above, the static chain within IR packets can be of
>    arbitrary length, and the chain is terminated by the presence of a
>    non-IP header (not IPinIP nor IPv6). Alternatively, the chain may be
>    explicitly terminated with a special value in the IP version field,
>    as described in section 3.1. The dynamic chain is structured
>    analogously.
>
>
> OLD (part of 3.5):
>    1) By using an IR packet as in ROHC UDP, where the profile is
>      0x0004, and the static chain ends with the static part of an
>      IP header, where the Next Header/Protocol field has any value but
>      IPinIP (4) or IPv6 (41) [PROTOCOL]. At the compressor, SN is
>      initialized to a random value when the first IR packet is sent.
>
>    2) By reusing an existing context. This is done with an IR-DYN
>      packet, identifying profile 0x0004, where the dynamic chain
>      corresponds to the prefix of the existing static chain, ending
>      with an IP header where the Next Header/Protocol field has any
>      value but IPinIP (4) or IPv6 (41) [PROTOCOL]. At the compressor,
>      SN is initialized to a random value when the first IR-DYN packet
>      is sent.
>
> NEW (part of 3.5):
>    1) By using an IR packet as in ROHC UDP, where the profile is
>      0x0004, and the static chain ends with the static part of an
>      IP header, where the Next Header/Protocol field has any value but
>      IPinIP (4) or IPv6 (41) [PROTOCOL], or where the IP version field
>      indicates termination (see section 3.1). At the compressor, SN
>      is initialized to a random value when the first IR packet is sent.
>
>    2) By reusing an existing context. This is done with an IR-DYN
>      packet, identifying profile 0x0004, where the dynamic chain
>      corresponds to the prefix of the existing static chain, ending
>      with an IP header where the Next Header/Protocol field has any
>      value but IPinIP (4) or IPv6 (41) [PROTOCOL], or where the IP
>      version field indicates termination (see section 3.1). At the
>      compressor, SN is initialized to a random value when the first
>      IR-DYN packet is sent.

Agreed this was valid, reasonable - asked for final check from WG,
and gave a look to the IESG, pointing out that the doc had had no
IESG Discusses, so this could not be touching a previous problem
area.

> From: "Lars-Erik Jonsson (LU/EAB)"  erik.jonsson@ericsson.com>
> To: "'mankin@bell-labs.com'"
> Cc: "'Carsten Bormann (E-mail)'"
> Subject: FW: [rohc] Limiting the number of IP header in IP-
> only profile
> Date: Mon, 24 May 2004 16:56:04 +0200
> -------
>
>
> Allison,
>
> The ROHC IP profile was approved early this year and is currently in
> the IANA queue for profile number assignment. The profile has been
> implemented and early interop testing of
> real-world implementations
> has unfortunately exposed a weakness that we were not
> able to notice
> with experimental implementations, which might make memory management
> very troublesome. The problem is specific to the IP profile, and
> we believe it should be addressed as soon as possible.
>
> Apart from discussions between the implementers, we've had
> discussions on the mail list and there seem to be consensus among
> those who have previously contributed to or reviewed this work to
> fix the problem. Below, you can find the change proposal we have
> produced, which has been acked by the "committed document reviewers"
> of the IP profile.
>
> My question is now, would it be possible to get this in before the
> RFC is published, i.e. can we get your permission to send this as
> a change request to the RFC editor (now or in AUTH 48)? When this
> first was brought up, I said no as I do not like making changes at
> this stage of the publication process, but I have been convinced
> the problem is important enough to try to address.
>
> Please let us know how to proceed.
>
> Thanks!
> /Lars-Erik
>
>
> -----Original Message-----
> From: Lars-Erik Jonsson (LU/EAB)
> Sent: den 11 maj 2004 14:47
> To: Lars-Erik Jonsson (LU/EAB); 'Kristofer Sandlund'; rohc@ietf.org
> Subject: RE: [rohc] Limiting the number of IP header in IP-only profile
>
>
> Me and Kristofer have discussed this issue further and come up with
> a change proposal. Please let us know what you think, both about the
> technical issue/resolution as well as how we should move on with it.
> Kristofer has convinced me that this is important for real-world
> implementations, so our take on it is that we should try to get this
> into the IP profile before publication, if at all possible.
>
> BR
> /L-E
>
>
> ***** CHANGE PROPOSAL FOR THE IP PROFILE *****
>
>
> OLD:
> 3.1.  Static Chain Termination
>    One difference for IP-only compression, compared to IP/UDP
>    compression, is related to the termination of the static chain in IR
>    headers. For the UDP profile, the chain always ends with a UDP header
>    part, which per definition provides the boundaries for the chain. The
>    UDP header is also the last header in the uncompressed packet (except
>    for a potential application header). For the IP-only profile, there
>    is no single last header that per profile definition terminates the
>    chain. Instead, the static chain is terminated if the "Next Header /
>    Protocol" field of a static IP header part indicates anything but IP
>    (IPinIP or IPv6).
>
> NEW:
> 3.1.  Static Chain Termination
>    One difference for IP-only compression, compared to IP/UDP
>    compression, is related to the termination of the static chain in IR
>    headers. For the UDP profile, the chain always ends with a UDP header
>    part, which per definition provides the boundaries for the chain. The
>    UDP header is also the last header in the uncompressed packet (except
>    for a potential application header). For the IP-only profile, there
>    is no single last header that per profile definition terminates the
>    chain. Instead, the static chain is terminated if the "Next Header /
>    Protocol" field of a static IP header part indicates anything but IP
>    (IPinIP or IPv6). Alternatively, the compressor can choose to end the
>    static chain at any IP header, and indicate this by setting the MSB
>    of the IP version field to 1 (0xC for IPv4 or 0xE for IPv6). The
>    decompressor must store this indication in the context for correct
>    decompression of subsequent headers. Note that the IP version field
>    in decompressed headers must be restored to its original value.
>
>
> OLD (part of 3.2):
>    As explained above, the static chain within IR packets can be of
>    arbitrary length, and the chain is terminated by the presence of a
>    As explained above, the static chain within IR packets can be of
>    arbitrary length, and the chain is terminated by the presence of a
>    non-IP header (not IPinIP nor IPv6). The dynamic chain is structured
>    analogously.
>
> NEW (part of 3.2):
>    As explained above, the static chain within IR packets can be of
>    arbitrary length, and the chain is terminated by the presence of a
>    non-IP header (not IPinIP nor IPv6). Alternatively, the chain may be
>    explicitly terminated with a special value in the IP version field,
>    as described in section 3.1. The dynamic chain is structured
>    analogously.
>
>
> OLD (part of 3.5):
>    1) By using an IR packet as in ROHC UDP, where the profile is
>      0x0004, and the static chain ends with the static part of an
>      IP header, where the Next Header/Protocol field has any value but
>      IPinIP (4) or IPv6 (41) [PROTOCOL]. At the compressor, SN is
>      initialized to a random value when the first IR packet is sent.
>
>    2) By reusing an existing context. This is done with an IR-DYN
>      packet, identifying profile 0x0004, where the dynamic chain
>      corresponds to the prefix of the existing static chain, ending
>      with an IP header where the Next Header/Protocol field has any
>      value but IPinIP (4) or IPv6 (41) [PROTOCOL]. At the compressor,
>      SN is initialized to a random value when the first IR-DYN packet
>      is sent.
>
> NEW (part of 3.5):
>    1) By using an IR packet as in ROHC UDP, where the profile is
>      0x0004, and the static chain ends with the static part of an
>      IP header, where the Next Header/Protocol field has any value but
>      IPinIP (4) or IPv6 (41) [PROTOCOL], or where the IP version field
>      indicates termination (see section 3.1). At the compressor, SN
>      is initialized to a random value when the first IR packet is sent.
>
>    2) By reusing an existing context. This is done with an IR-DYN
>      packet, identifying profile 0x0004, where the dynamic chain
>      corresponds to the prefix of the existing static chain, ending
>      with an IP header where the Next Header/Protocol field has any
>      value but IPinIP (4) or IPv6 (41) [PROTOCOL], or where the IP
>      version field indicates termination (see section 3.1). At the
>      compressor, SN is initialized to a random value when the first
>      IR-DYN packet is sent.

[Ballot comment]
>    One difference for IP-only compression, compared to IP/UDP
>    compression, is related to the termination of the static chain in IR
>    headers. For the UDP profile, the chain always ends with a UDP header

what is IR? (oh, mentioned later and defined in another doc). would be
good to expand on first usage.

References not split

Significant amounts of WG review occurred, led by co-chair, since other co-chair is an author...Applicability could be more clearly stated, but the context is IP tunnels in particular.

[Note]: 'Significant amounts of WG review occurred, led by co-chair, since other co-chair is an author...Applicability could be more clearly stated, but the context is IP tunnels in particular.' added by Allison Mankin