Skip site navigation (1)Skip section navigation (2)
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>