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

Mark Allman <mallman@grc.nasa.gov> Wed, 18 December 2002 15:37 UTC

Message-Id: <200212181537.KAA27795@guns.lerc.nasa.gov>
To: tcp-impl@grc.nasa.gov
From: Mark Allman <mallman@grc.nasa.gov>
Reply-To: mallman@grc.nasa.gov
Subject: FWD:: Re: [e2e] Re: Question on "identification" field of IP header
Organization: BBN Technologies/NASA GRC
Song-of-the-Day: Not Fade Away
Date: Wed, 18 Dec 2002 10:37:05 -0500
Sender: owner-tcp-impl@grc.nasa.gov
Precedence: bulk
Status: RO
Content-Length: 3051
Lines: 88

 

------- Forwarded Message

Date: Mon, 16 Dec 2002 14:14:05 -0800
From: "Fred L. Templin" <ftemplin@iprg.nokia.com>
To: Kevin Fall <kfall@EECS.Berkeley.EDU>
Cc: David Borman <dab@bsdi.com>, end2end-interest@postel.org,
   mouse@Rodents.Montreal.QC.CA, tcp-impl@grc.nasa.gov
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
ftemplin@iprg.nokia.com

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 <dab@bsdi.com>
>>To:    end2end-interest@postel.org, mouse@Rodents.Montreal.QC.CA,
> 
> 	 tcp-impl@grc.nasa.gov
> 
>>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:
>>
>>
>>>From: der Mouse <mouse@Rodents.Montreal.QC.CA>
>>>Date: Fri, 13 Dec 2002 16:41:51 +0100 (CET)
>>>Subject: Re: Question on "identification" field of IP header
>>
>>...
>>
>>>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
> 
> 



------- End of Forwarded Message