Subject: (IPng 6549) Re: draft-ietf-ipngwg-icmp-v2-02.txt

From: [email-masked]
Date: Mon, 28 Sep 1998 14:45:50 EDT

I have to ask the following.

"What if the fragments travel different paths between the source and the
destination
and only a fragment with a non-zero offset reaches a network where the size
of the fragment is too large?"

Joachim Martillo
<A HREF="http://members.aol.com/Telford001/">Telford Tools, Inc.</A> 

In a message dated 9/28/98 12:53:41 PM Eastern Daylight Time,
[email-masked] writes:

> I was recently reading the IPsec documents and realized that there is a
>  problem with the ICMPv6 spec.
>  
>  The problem is that the ICMPv6 spec does not say anything about whether
ICMP
>  errors should be sent in response to fragments with a non-zero offset. In
>  the v4 world, this is prohibited. (Eg see section 4.3.2.7 of RFC 1812.) I
>  believe it is desirable to prohibit this for v6 as well.
>  
>  The reason IPsec brought this to mind is that with IPsec, in some cases a
>  sender might want to maintain path MTU information at the level of
>  upper-layer (eg TCP or UDP) connections. This is because different
>  upper-layer connections originated by the sender might be subject to
>  different security processing in the network, with differently-sized IPsec
>  headers added to the packets.
>  
>  As a consequence, the sender wants to receive Packet Too Big messages that
>  contain the upper-layer protocol data so it can pass the path MTU
>  information to the appropriate upper-layer connection.
>  
>  Now consider the case of a sender that habitually sends fragments out of
>  order, eg, sends the last fragment first. (I've observed implementations
>  that do this.) When the fragments arrive at a router with a new MTU
>  bottleneck, the router will generate a Packet Too Big for the first
fragment
>  that it sees. This will be a fragment with a non-zero offset, so it won't
>  have the upper-layer protocol data.
>  
>  Because the router will implement ICMP error rate-limiting, it might not
>  generate Packet Too Big errors for the subsequent fragments. This will be
>  the case with any rate-limiting implementation that limits the errors to
one
>  per some time interval - one of the suggested algorithms.
>  
>  So in this situation, the sender will *never* get a Packet Too Big error
>  with the upper-layer information that it wants to see.
>  
>  Preventing the generation of ICMP errors in response to fragments with a
>  non-zero offset fixes this problem.
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------