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.

Regards,
	-is
-- 
seal your e-mail: http://www.gnupg.org/