RE: Evolution of the IP model - ICMP and MTUs

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

> -----Original Message-----
> From: owner-v6ops@ops.ietf.org 
> [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Rémi Després
> Sent: Saturday, August 16, 2008 9:59 AM
> To: Christian Huitema
> Cc: Dave Thaler; v6ops
> Subject: Re: Evolution of the IP model - ICMP and MTUs
> 
> Christian Huitema  - Le 8/15/08 10:14 PM :
> > If you want to document the evolution, you have to be complete.
> > 
> > 1) In the original model, senders of datagrams with the DF bit set
> >  (Don't Fragment) received  no information back.
> > 2) In 1990, the Next-Hop MTU information was added to 
> Datagram Too Big
> >  ICMP message (RFC 1191).
> >         Hosts have a chance to discover the real MTU in the 
> path using ICMP
> > 3) Around 1995, firewalls started to drop all ICMP by default
> >         Hosts that rely on ICMP to discover PMTU observe 
> terrible performance
> > 4) Around 2000, broadband connections start being equipped 
> with tiny "home
> >    routers" whose NAT function does a pretty bad job at 
> reassembling IP packets
> >         Hosts that send packets too large observe terrible 
> performance, and they
> >         are in a bind since PMTU discovery does not work well.
> > 5) By 2008, the IETF might recognize that firewalls are 
> here to stay,
> >    that we could just as well forget about ICMP, but that we really
> >    need another solution.
> 
> - Well, I don't "want" anything here. Just trying to answer Dave's 
> invitation to comment.
> - Please note that I did mention that "some firewalls filter 
> ICMP packets".
> - IMU, your more detailed comments are worth being included 
> too (except 
> 5., wich is a comment about the future).
> - In particular a brief summary of what you mean by "a pretty 
> bad job at 
> reassembling packets" should IMO have its place in Dave's 
> document, its 
> scope being the evolution of the IP model.

A NAPT -- like a host -- has a limited amount of resources it
wants to dedicate to reassembling fragments.  But a NAPT is
in front of many hosts (and thus sees more fragments than
any one host).  To perform its NAPT function, the NAPT needs 
to see the first fragment (containing port numbers); if the
packets arrive out of order, the NAPT needs to (a) discard
the fragments [causing the entire packet to be lost] or 
(b) store the fragments until the first fragment arrives or
until a timer expires.

See also RFC 4963, "IPv4 Reassembly Errors at High Data Rates"
(used to be titled "Fragmentation Considered Very Harmful").

-d



> Regards,
> 
> Rémi Després
> 
>