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

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

------- Forwarded Message

From: "alok" <[email-masked]>
To: "der Mouse" <[email-masked]>, <[email-masked]>,
   <[email-masked]>
Subject: Re: [e2e] Re: Question on "identification" field of IP header
Date: Fri, 13 Dec 2002 22:18:46 +0530

think about the usage of that fields in ATM and MPLS core scenarios....
TCP_MSS can get screwed up...

- ----- Original Message ----- 
From: der Mouse <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Sent: Friday, December 13, 2002 9:11 PM
Subject: [e2e] Re: Question on "identification" field of IP header

> > If the "Don't fragment bit" is set in the IP header, what purpose
> > does the "identification" field serve?
> 
> It says which datagram is affected if an ICMP is returned in resposne
> to it, if nothing else.
> 
> > 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.
> 
> Heh.  My usual response to "NAT interacts badly with <foo>" is "don't
> use NAT, then".  It just breaks too many of the assumptions underlying
> IP-based networking.  But it wouldn't surprise me a bit if there were
> NAT implementations broken enough to assume that packets with identical
> IDs arriving within a small enough temporal window of one another were
> actually the same packet.
> 
> 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....
> 
> /~\ The ASCII der Mouse
> \ / Ribbon Campaign
>  X  Against HTML        [email-masked]
> / \ Email!      7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B
> 

------- End of Forwarded Message

---

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

Date: Mon, 16 Dec 2002 14:14:05 -0800
From: "Fred L. Templin" <[email-masked]>
To: Kevin Fall <[email-masked]>
Cc: David Borman <[email-masked]>, [email-masked],
   [email-masked], [email-masked]
Subject: Re: [e2e] Re: Question on "identification" field of IP header

Kevin,

Just wondering - do you have any idea of the proportion of
implementations in the installed base that still implement the old
standard vs. those that implement the "SHOULD" from rfc1812? It seems
to me that a number of operational issues could be resolved if the
outdated implementations were to move forward - any thoughts on how
to encourage this among vendors?

Thanks,

Fred Templin
[email-masked]

Kevin Fall wrote:
> 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]
> 
>>Subject: Re: Question on "identification" field of IP header
>>Date:  Fri, 13 Dec 2002 11:14:11 CST
>>
>>Just a minor nit that I feel should be clarified:
>>
>>
>>>Date: Fri, 13 Dec 2002 16:41:51 +0100 (CET)
>>>Subject: Re: Question on "identification" field of IP header
>>
>>...
>>
>>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
> 
>