In message <20041202212905.GE1005@beverly.kleinbus.org>, Ignatios Souvatzis wri
tes:
>On Thu, Dec 02, 2004 at 03:43:14PM -0500, Steven M. Bellovin wrote:
>> In message <20041202200043.GA1005@beverly.kleinbus.org>, Ignatios Souvatzis 
>wri
>> tes:
>> 
>> >
>> >On Thu, Dec 02, 2004 at 08:34:50PM +0100, Konstantin KABASSANOV wrote:
>> >> Well, I've probably taken the wrong way to debug but:
>> >>=20
>> >> >ping6 -s 1300 my-ipv6-address
>> >>=20
>> >> gives me icmp packets fragmented to payload 1232 and additional fragments
>> >> of 76 bytes...
>> >
>> >I can reproduce this with a 1.6.2/arm32 pinging 1.6.2/i386.
>> >
>> >However, when I produce UDP packets (using traceroute6 ) fragmentation
>> >starts at "datasize" 1428 bytes, I think as expected.
>> >
>> >Now, for the ICMPv6 handling:=20
>> >
>> >what _I_ am seeing is that the _reply_ is fragmented, but not the request.
>> >(Konstantin: is this what you are seeing, too?)
>> >
>> >So I think the ICMPv6 reply machinery limits to the minimum IPv6 MTU of=20
>> >1280 bytes, always, which might conform to RFC2463 on a quick reading.
>> >What looks odd is that it fragments, instead of discarding the data
>> >going over the limit (which I'd expect for ICMPv6 special handling).
>> >
>> 
>> IPv6 doesn't have fragmentation in the network; it relies on Path MTU 
>> and fragmentation by the sender.  But Path MTU is difficult for 
>> protocols that aren't connection-oriented.  I'm thus not surprised to 
>> hear that ICMP or UDP fragments intentionally at the 1280 limit.
>
>No... our UDP fragments at the link limit, for one-hop routes. our ICMP
>fragments at 1280 bytes... instead of _limiting the output_ to 1280 bytes
>which I would expect from reading RFC 2463.
>

For one-hop routes, I agree that that's the correct behavior.  I should 
have distinguished one-hop from multi-hop situations in my note.

		--Steve Bellovin, http://www.research.att.com/~smb