Re: Problem of blocking ICMP packets
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Problem of blocking ICMP packets



On Mon, 10 May 2004 10:55:43 +0900
Masataka Ohta <mohta at necom830.hpcl.titech.ac.jp> wrote:

> Dean Anderson;
> 

> > A number of commercial
> > products and applications do rely on PMTU to work, and will
> > do an PATH MTU discovery, and send the MTU sized packets with
> > DF (don't frag).
> 
> and send packets larger than MTU expecting to receive ICMP
> errors in vain.
> 
> Read the original mail of the thread on the reality.
> 

The problem identified has nothing to do with the concept or
typical implementations of PMTUD being broken.

RFC1192 (http://www.rfc-editor.org/rfc/rfc1191.txt) is the spec
for PMTUD. 

The issue that PMTUD is addressing is :

"1. Introduction

   When one IP host has a large amount of data to send to another
host, the data is transmitted as a series of IP datagrams.  It
is usually preferable that these datagrams be of the largest
size that does not require fragmentation anywhere along the path
from the source to the  destination.  (For the case against
fragmentation, see [5].)  This datagram size is referred to as
the Path MTU (PMTU), and it is equal to the minimum of the MTUs
of each hop in the path. A shortcoming of the current Internet
protocol suite is the lack of a standard mechanism for a host
to discover the PMTU of an arbitrary path."

PMTUD is a performance optimisation, specifically a throughput
optimisation. 

The problem being discussed is directly caused by broken
firewall/NAT devices or configurations, blocking network
management traffic (ie. ICMP Destination Unreachable,
Fragmentation Needed and Don't Fragment was Set) that they
should be permitting.

Regards,
Mark.


_______________________________________________
Ietf mailing list
Ietf at ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.

Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.