Subject: FWD:: Re: Question on "identification" field of IP header

From: Mark Allman <[email-masked]>
Date: Wed, 18 Dec 2002 10:35:40 -0500

------- Forwarded Message

Date: Fri, 13 Dec 2002 15:42:08 -0500
From: Felix Hernandez-Campos <[email-masked]>
To: end2end <[email-masked]>, TCP-IMPL <[email-masked]>
Subject: Re: Question on "identification" field of IP header

Ramesh Shankar wrote:
> If the "Don't fragment bit" is set in the IP header, what purpose does 
> the "identification" field serve? Why can't I simply put 0 for this 
> field in such a case? I remember coming across some e-mail chain in one 
> of the mailing lists (TCP-IMPL, e2e, TSVWG) about this issue and the 
> interaction with NAT. But I am not sure what came out of that discussion.

You may want to have a look at Steve Bellovin's "A Technique for 
Counting NATed Hosts", presented at IMW 2002. The paper discusses how 
the IP header's ID field can be used to infer the number of hosts behind 
a NAT box.

Regards,
Felix.

- -- 
Felix Hernandez-Campos
http://www.cs.unc.edu/~fhernand

------- End of Forwarded Message

---

From: Mark Allman <[email-masked]>
Date: Wed, 18 Dec 2002 10:34:58 -0500

To: David Borman <[email-masked]>
Cc: [email-masked], [email-masked],
   [email-masked]
Subject: Re: Question on "identification" field of IP header 
Date: Fri, 13 Dec 2002 10:42:28 -0800
From: Kevin Fall <[email-masked]>

And, the including of 64-bits of "data" was later updated by rfc1812:

... 

4.3.2.3 Original Message Header
       
   Historically, every ICMP error message has included the Internet
   header and at least the first 8 data bytes of the datagram that
   triggered the error.  This is no longer adequate, due to the use of
   IP-in-IP tunneling and other technologies.  Therefore, the ICMP
   datagram SHOULD contain as much of the original datagram as possible
   without the length of the ICMP datagram exceeding 576 bytes.  The
   returned IP header (and user data) MUST be identical to that which
   was received, except that the router is not required to undo any
   modifications to the IP header that are normally performed in
   forwarding that were performed before the error was detected (e.g.,
   decrementing the TTL, or updating options).  Note that the
   requirements of Section [4.3.3.5] supersede this requirement in some
   cases (i.e., for a Parameter Problem message, if the problem is in a
   modified field, the router must undo the modification).  See Section
   [4.3.3.5]).

...

- - K

>
> From:  David Borman <[email-masked]>
> To:    [email-masked], [email-masked],
	 [email-masked]
> Date:  Fri, 13 Dec 2002 11:14:11 CST
>
> Just a minor nit that I feel should be clarified:
> 
> > From: der Mouse <[email-masked]>
> > Date: Fri, 13 Dec 2002 16:41:51 +0100 (CET)
> ...
> > Note that the portion of a packet returned in an ICMP does not include
> > even the IP source and destination addresses; the identification value
> > is almost the only value that can be relied upon to identify the
> > original packet upon getting an ICMP....
> 
> Actually, ICMP packets are supposed to return the entire IP header
> (including options) plus 64 bits of the IP data.  So, you should get
> up to the TCP and UDP port numbers.  (RFC 792 explicitly states
> that it assumes that higher level protocols have their port numbers
> in the first 64 bits).
> 
> 			-David Borman