From: Volkov, Dmitry (IDS Canada) (dmitry_volkov@ca.ml.com)
Date: Sun Jun 29 2003 - 19:58:41 GMT-3
I was blind new next Hop MTU is inside ICMP 3 4:
7 and 8 th bytes of ICMP header.
To support the Path MTU Discovery
technique specified in this memo, the router MUST include the MTU of
that next-hop network in the low-order 16 bits of the ICMP header
field that is labelled "unused" in the ICMP specification [7]. The
high-order 16 bits remain unused, and MUST be set to zero.
http://www.ietf.org/rfc/rfc1191.txt
http://www.cisco.com/en/US/tech/tk827/tk369/technologies_white_paper09186a00
800d6979.shtml#second
Thanks, Howard.
Dmitry
> -----Original Message-----
> From: Howard C. Berkowitz [mailto:hcb@gettcomm.com]
> Sent: Sunday, June 29, 2003 5:34 PM
> To: ccielab@groupstudy.com
> Cc: 'security@groupstudy.com'
> Subject: Re: reaction on ICMP 3 4
>
>
> At 5:09 PM -0400 6/29/03, Volkov, Dmitry (IDS Canada) wrote:
> >How TCP/IP stack reacts on receiving ICMP type 3 code 4
> Fragmentation needed
> >but DF set ?
> >I mean how many bytes will be sent next time after receiving ICMP
> >unreachable.
> >I lowered IP mtu to 1420 and router sent ICMP and host
> started send 1420 !!
> >I sniffed ICMP packed and I didn't see anything inside ICMP
> indicating
> >allowable MTU.
> >How source knows what size frame to retransmit ?
> >
>
> More information is needed to answer this. Is the host actively
> participating in MTU autodiscovery, or is it just setting DF? There
> are valid reasons for the latter. For example, the old IBM RSRB
> method of Fast Sequenced Transport sets DF, and then steals the
> fragmentation fields in the header for IBM information.
>
> In any case, this is going to be a host implementation matter.
This archive was generated by hypermail 2.1.4 : Fri Jul 04 2003 - 11:11:14 GMT-3