Subject: (IPng 6548) RE: draft-ietf-ipngwg-icmp-v2-02.txt

From: Richard Draves <[email-masked]>
Date: Mon, 28 Sep 1998 09:32:31 -0700

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.

Rich

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Friday, September 25, 1998 7:26 AM
> Cc: [email-masked]
> Subject: I-D ACTION:draft-ietf-ipngwg-icmp-v2-02.txt
> 
> 
> Note: This revision reflects comments received during the 
> last call period.
> 
> A New Internet-Draft is available from the on-line 
> Internet-Drafts directories.
> This draft is a work item of the IPNG Working Group of the IETF.
> 
> 	Title		: Internet Control Message Protocol (ICMPv6) 
>                           for the Internet Protocol Version 6 
> (IPv6) Specification
> 	Author(s)	: A. Conta, S. Deering
> 	Filename	: draft-ietf-ipngwg-icmp-v2-02.txt
> 	Pages		: 21
> 	Date		: 24-Sep-98
> 	
>    This document specifies a set of Internet Control Message Protocol
>    (ICMP) messages for use with version 6 of the Internet Protocol
>    (IPv6).
> 
> Internet-Drafts are available by anonymous FTP.  Login with 
> the username
> "anonymous" and a password of your e-mail address.  After logging in,
> type "cd internet-drafts" and then
> 	"get draft-ietf-ipngwg-icmp-v2-02.txt".
> A URL for the Internet-Draft is:
> ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipngwg-icmp-v2-02.txt
> 
> Internet-Drafts directories are located at:
> 
> 	Africa:	ftp.is.co.za
> 	
> 	Europe: ftp.nordu.net
> 		ftp.nis.garr.it
> 			
> 	Pacific Rim: munnari.oz.au
> 	
> 	US East Coast: ftp.ietf.org
> 	
> 	US West Coast: ftp.isi.edu
> 
> Internet-Drafts are also available by mail.
> 
> Send a message to:	[email-masked].  In the body type:
> 	"FILE /internet-drafts/draft-ietf-ipngwg-icmp-v2-02.txt".
> 	
> NOTE:	The mail server at ietf.org can return the document in
> 	MIME-encoded form by using the "mpack" utility.  To use this
> 	feature, insert the command "ENCODING mime" before the "FILE"
> 	command.  To decode the response(s), you will need "munpack" or
> 	a MIME-compliant mail reader.  Different MIME-compliant 
> mail readers
> 	exhibit different behavior, especially when dealing with
> 	"multipart" MIME messages (i.e. documents which have been split
> 	up into multiple messages), so check your local documentation on
> 	how to manipulate these messages.
> 		
> 		
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
> 
--------------------------------------------------------------------
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]
--------------------------------------------------------------------

---

From: "Matt Crawford" <[email-masked]>
Date: Mon, 28 Sep 1998 15:07:07 -0500

> [...]

No. it just pops up in a different place.  Suppose the host is in the
habit of fragmenting packets "from the end", sending N-1 full-size,
non-initial fragments and an intiall, probably smaller fragment.
Never mind which order they're sent in, your suggestion could stop
the host from getting changed PMTU information.

And, we can imagine that for an extended period, fragments are
load-shared across a number of equal-cost paths which just happens to
equal the number of fragments which compose a typical packet.  Then
all the initial fragments take the same path for a while, and if the
MTU of one of the other paths shrinks, the router would never be
allowed to send a message.
--------------------------------------------------------------------
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]
--------------------------------------------------------------------