RE: Evolution of the IP model - ICMP and MTUs

["Dan Wing" <dwing@cisco.com>]

I don't recall if RFC4821 was included in your earlier list.  RFC4821
describes how to do Path MTU Discovery without ICMP.  

As you know, doing PMTUD over UDP requires each application to do it
themselves.  Marc Petit-Huguenin describes how to do RFC4821-style (that is,
ICMP-less) PMTUD for UDP in draft-petithuguenin-behave-stun-pmtud-01, provided
the application can demultiplex STUN messages from its normal application
payloads (the STUN magic-cookie and the STUN fingerprint can be used to demux,
which makes demuxing easier).

-d


> -----Original Message-----
> From: Rémi Després [mailto:remi.despres@free.fr] 
> Sent: Sunday, August 17, 2008 11:46 PM
> To: 'Dave Thaler'; Dan Wing
> Cc: 'v6ops'
> Subject: Re: Evolution of the IP model - ICMP and MTUs
> 
> 
> 1.
> Thanks Dan for the ref. to RFC 4963. I had not noticed this RFC, 
> important as far as the evolution of the IPv4 model is concerned.
> 
> IMU, since it shows that, at high data rates, IPv4 fragmentation can 
> lead to undetected data corruption at the IP layer, it implies that 
> fragmentation SHOULD be discarded from an updated IPv4 service model 
> (the DF bit MUST be set in all packets).
> 
> Applications that can send datagrams longer than typical MTUs (AFAIK, 
> Sun NFS needs 8 K) can still work in strict conformity with the IP 
> model, but in IPv6.
> 
> 2.
> With no fragmentation in the IPv4 model, packet losses due to
> insufficient reassembly resources are no longer a concern.
> 
> 3.
> Where ICMP is not filtered by FWs, upper layers can take advantage of
> MTU information which, since RFC 1191 of 1990, may be 
> returned in Packet 
> too Big ICMP massages.
> 
> Rémi Després
>