Date: Thu, 30 Dec 1999 10:44:16 -0800 From: "Justin C. Walker" <justin@apple.com> To: Fernando Ariel Gont <fgont@softhome.net> Cc: freebsd-net@FreeBSD.ORG Subject: Re: "Identification field" at the IP header Message-ID: <199912301844.KAA00666@rhapture.apple.com> In-Reply-To: <199912290204.SAA01331@walker3.apple.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> From: Fernando Ariel Gont <fgont@softhome.net> > Date: 1999-12-30 03:02:49 -0800 > To: justin@apple.com > Subject: Re: "Identification field" at the IP header > Cc: freebsd-net@FreeBSD.ORG > In-reply-to: <199912290204.SAA01331@walker3.apple.com> > X-Sender: fgont@pop.softhome.net > X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 > > At 18:04 28/12/1999 -0800, Justin C. Walker wrote: > > > >I'm not sure where you read this, or what implementations do it. > > I read that from Richard Stevens' "TCP/IP Illustrated, Volume I" > (Addison-Wesley), on page 36. > It says: > ".... RFC 791 says that the identification field should be chosen by the upper > layer that is having IP send the datagram. This implies that two consecutive IP > datagrams, one generated by TCP and one generated by UDP, can have the same > identification field. While this is OK (the reassembly algorithm handles > this), most Berkeley-derived implementations have the IP layer increment a > kernel variable each time an IP datagram is sent, regardless of which layer > passed the data to IP to send. This kernel variable is initialized to a value based > on the time-of-day when the system is bootstraped" Gee. Another day, another change in what one "knows"... Actually, it (RFC 791) sez that "it is appropriate for *some* upper level protocols" to choose the ID (emphasis mine), and goes on to discuss why this might be so. In any case, I'm not aware of any that do. At the same time, keep in mind that reassembly typically relies on several pieces of info (RFC 791 again): addresses, ID, and protocol. Given that, IDs could certainly have different "name spaces", depending on transport protocols. > >The "identification" is supposed to be unique to a given datagram. > >Having it assigned by another agent than the IP layer makes this > >either difficult or an excercise in semantics (e.g., the TCP could > >specify it, using a value provided by the IP layer). > > What I understand from Stevens' words is that the Identification is chosen by the > upper layer (say TCP or UDP)... :( > > I don't understand why it is possible that the Identification number is chosen by > TCP or UDP, as if a packet is fragmented, neither TCP nor UDP are aware of it. I think you're confusing definition/specification and implementation. The RFC allows this, but it doesn't *require* it. In fact those I'm aware of don't do this, and instead have the IP layer assign the ID. The point to the assignment of an ID is to provide for fragmentation and reassembly. Generally, there's no guarantee (for IPv4) that the sending TCP will know it's happening in any case (even if the sending IP doesn't fragment, and intervening one might). Regards, Justin -- Justin C. Walker, Curmudgeon-At-Large * Institute for General Semantics | Manager, CoreOS Networking | Men are from Earth. Apple Computer, Inc. | Women are from Earth. 2 Infinite Loop | Deal with it. Cupertino, CA 95014 | *-------------------------------------*-------------------------------* To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199912301844.KAA00666>