IP identifier field for linux UDP/IP equals zero??!
mmc at mmc.com.au
Thu May 15 09:24:10 CST 2003
You're a programmer - You've got the source.
Rewrite it to your hearts content and then submit it to Linus or one of his
There's no "officialness" about the LK - you should know this already.
> RFC 791, pages 8, doesn't seem to agree:
Selective quoting by you Alan. Previous paragraph:
The internet fragmentation and reassembly procedure needs to be able
to break a datagram into an almost arbitrary number of pieces that
can be later reassembled. The receiver of the fragments uses the
identification field to ensure that fragments of different datagrams
are not mixed. The fragment offset field tells the receiver the
position of a fragment in the original datagram. The fragment
offset and length determine the portion of the original datagram
covered by this fragment. The more-fragments flag indicates (by
being reset) the last fragment. These fields provide sufficient
information to reassemble datagrams.
Which says exactly that the id field is for fragments only.
> 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.
> Some humans have also informed me in the last hour that in fact
> the linux implementation does contradict RFC 791.
> There is no indication that I can find in RFC 791 that an exception
> to the rule is made for packets with the DF bit set.
> You're right about the stated purpose of the ID field.
> However, when someone writes a spec and people implement that spec,
> then other people who write other specs assuming that everyone will
> implement the IP protocol according to the spec, it's very inconvenient
> when someone chooses to break the spec for all machine using
> a particular operating system, in this case linux.
> That's what's happened in this case. It's an embarrassment that
> linux has acted on the assumption that the RFC can be improved upon,
> in the just the same way that MS-Windows "improves" TCP 3-way handshakes
> to 1-way handshakes.
> In the linux case, this makes another IETF protocol work at 50% efficiency
> because of the zero ID fields.
> > While I'm sure it'd be convenient for your application if the standard
> > required more from the Identification field, it actually doesn't. It's
> > possible that some TCP/IP stacks set it on every IP packet, but they're
> > going above and beyond the requirements of the TCP/IP spec in doing so.
> Nope. It isn't "convenient" for my application. It's assumed by
> another, more recent RFC.
> > > Does anyone out there happen to know if there is some official
> > > excuse for why linux doesn't seem to do quite the right thing here?
> > You're making assumptions again :-)
> Everybody makes assumptions. Some assumptions are correct, and some are not.
> You can't function without assumptions in a complex world.
> And notice that little word "seems". That's not an assumption, is it.
> > Incidentally, you're probably seeing lots of packets with the DF bit set
> > because the IP stack is attempting to use Path MTU discovery (RFC 1191,
> > ftp://ftp.rfc-editor.org/in-notes/rfc1191.txt )
> Nope. It's because I'm running "ohphone" to generate voice RTP packets,
> which all use DF.
> They're coming out every 80 mSec, although I can set it to 20 mSec.
> This is less than the
> "time the datagram will be active in the internet system"
> for even my 19200 bits/sec null modem in the lab.
> Alan Kennington.
Matthew at Moyle-Croft.com | mmc at mmc.com.au | mmc at 206gti.net
http://www.Moyle-Croft.com | http://www.mmc.com.au | http://206gti.net
LinuxSA WWW: http://www.linuxsa.org.au/ IRC: #linuxsa on irc.freenode.net
To unsubscribe from the LinuxSA list:
mail linuxsa-request at linuxsa.org.au with "unsubscribe" as the subject
More information about the linuxsa