Subject: RE: [rohc] Re: [tcpm] WG last-call of TCP header compression

From: "Lars-Erik Jonsson (LU/EAB)" <[email-masked]>
Date: Tue, 27 Sep 2005 18:48:17 +0200

> > >- - sec 3.2 IP IDs are not valid if zeroed. If this has 
> > > changed after RFCs 791 and 1122, then please cite the
> > > change to those specs, but a zero IP...
> > 
> > We've been told on many occasions that the zero-IPID 
> > allocation is used in some Linux stacks, and also some
> > providers of cellular equipment have stated that they
> > will use such an assignment policy for non-fragments. 
> > Therefore, the spec tries to accommodate for behavior that 
> > we know that implementations will see "out in the wild".
> 
> It's important to distinguish between "out in the wild" variants and
> standards-violating bugs. This is the latter - regardless of whether
> it's seen out in the wild. It need not be supported, and should not be
> used as an example of anything other than a bug.

Well, RFC 791 is not very explicit on the IP-ID assignment. Of course,
if one ignores the actual purpose of the IP-ID and instead reads the
791 text like a lawyer, I guess one could claim setting it to 0 is a
standards-violation. However, that is not a very constructive way of
arguing. When we discussed this last time on the rohc list, we ended
up agreeing that setting IP-ID to 0 should e considered legal when DF
is set (based on how we interpreted the text in RFC 791).

(see the attached mail)

BR
/L-E

Subject: RE: [rohc] linux constant IP ID field can't be compressed in profile 0x0001?
From: "Lars-Erik Jonsson \(EAB\)" <[email-masked]>
To: <[email-masked]>
Date: Mon, 26 May 2003 08:38:12 +0200

Ashok,

RFC 791 says the following:

"Identification

    The choice of the Identifier for a datagram is based on the need to
    provide a way to uniquely identify the fragments of a particular
    datagram.  The protocol module assembling fragments judges fragments
    to belong to the same datagram if they have the same source,
    destination, protocol, and Identifier.  Thus, the sender must choose
    the Identifier to be unique for this source, destination pair and
    protocol for the time the datagram (or any fragment of it) could be
    alive in the internet."

971 does not make any exceptions for when the last sentence must be
followed, so one might interpret it as incorrect to set ID to 0, as in
linux. On the other hand, if one considers the whole text, one might
interpret it as a rule applicable only for datagrams that can be
fragmented.

As I said in a previous mail, for us it does not matter how we interpret
it, we will see linux implementations anyway. Therefore, we seem to have
consensus to address this in new profiles, but not to update profiles
only to address this issue.

BR
/L-E

> -----Original Message-----
> From: Ashok Kumar [mailto:[email-masked]]
> Sent: den 26 maj 2003 06:15
> To: Sukanta Kumar Hazra; [email-masked]
> Subject: RE: [rohc] linux constant IP ID field can't be compressed in
> profile 0x0001?
> 
> 
> Hi,
> 
> I think, RFC 791 does not imposes any restrictions on the mechanism of
> IP-ID is generated. It just requires the implementation to 
> generate the
> IP-ID in such a manner that IP fragments can be properly identified at
> the destination.
> 
> So I do not feel this behavior of IP stack can be termed as faulty. 
> I wonder if we need to take care of a IP-ID field, when it is 
> a constant
> in ROHC. Otherwise IP-ID field has to be sent as RANDOM, which will be
> an extra 2 Bytes per packet.
> 
> Please let me know what you feel about the issue.
> 
> Regards,
> Ashok
> 
> 
> 
> -----Original Message-----
> From: Sukanta Kumar Hazra [mailto:[email-masked]] 
> Sent: Thursday, May 15, 2003 4:35 PM
> To: [email-masked]
> Subject: Re: [rohc] linux constant IP ID field can't be compressed in
> profile 0x0001?
> 
> 
> > > Is there an obvious way to solve the problem of the constant value
> > > of the IP header Identifier field for UDP/IP from linux boxes?
> > 
> > Constant IP-ID?? It looks to me a faulty implementation (of 
> IP stack)
> > which defeats the exact purpose of IP-ID (see RFC 791).
> > 
> I had faced the same problem earlier (check list archives). Since the
> Linux stack behaviour is non standard, I guess its upto the Linux guys
> to fix it.
> 
> - Sukanta
> _______________________________________________
> Rohc mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/rohc
> _______________________________________________
> Rohc mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/rohc
> 
_______________________________________________
Rohc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rohc

---

From: Joe Touch <[email-masked]>
Date: Tue, 27 Sep 2005 11:42:02 -0700

Lars-Erik Jonsson (LU/EAB) wrote:
> standards-violation.

It doesn't take a lawyer to note that:
"The originating protocol module of
    an internet datagram sets the identification field to a value that
    must be unique for that source-destination pair and protocol for the
    time the datagram will be active in the internet system."

> However, that is not a very constructive way of

The ROHC group doesn't get to make that decision; you need to override
RFC791 as per above first with a standards-track mod to 791.

As to constructive, I've already listed a number of reasons that
repeating values within an MSL is hazardous. They may not be germane to
the TCP or FN docs, but they are relevant as to why it should not be
modified from RFC791.

Joe

> (see the attached mail)
> 
> BR
> /L-E
> 
> 
> ------------------------------------------------------------------------
> 
> Subject:
> RE: [rohc] linux constant IP ID field can't be compressed in profile 0x0001?
> From:
> "Lars-Erik Jonsson \(EAB\)" <[email-masked]>
> Date:
> To:
> <[email-masked]>
> To:
> <[email-masked]>