Dear Guy, Thank you for your response(s). You are absolutely correct. These packets were generated using a non-stateful packet generator, for performance, (not conformance) therefore we are merely editing the packets that are sent. That is how I was able to induce an incorrect checksum. Thanks for your time...we MUST do this again! :) /m
-----Original Message----- From: Guy Harris [mailto:[EMAIL PROTECTED] Sent: Thursday, October 31, 2002 11:42 AM To: Michele Bustos Cc: '[EMAIL PROTECTED]' Subject: Re: [Ethereal-users] extension headers ipv6 On Wed, Oct 30, 2002 at 03:15:47PM -0800, Michele Bustos wrote: > Here's one for ethereal! > Here is a packet with a TOTALLY incorrect checksum. The "other" trace > program never flagged it as incorrect. Ethereal gives the same malformed > error! Same problem as the last packet. Please fix whatever generates those ICMPv6 packets to put an IPv6 packet into the ICMPv6 packet after the ICMPv6 checksum. By the way, does your IPv6 conformance test suite check to make sure ICMPv6 error messages contain at least some of what appears to be an invoking message? It turns out that, according to section 2.4 of RFC 2463, implementations MUST include that information: 2.4 Message Processing Rules Implementations MUST observe the following rules when processing ICMPv6 messages (from [RFC-1122]): ... (c) Every ICMPv6 error message (type < 128) includes as much of the IPv6 offending (invoking) packet (the packet that caused the error) as will fit without making the error message packet exceed the minimum IPv6 MTU [IPv6]. (d) In those cases where the internet-layer protocol is required to pass an ICMPv6 error message to the upper-layer process, the upper-layer protocol type is extracted from the original packet (contained in the body of the ICMPv6 error message) and used to select the appropriate upper-layer process to handle the error. If the original packet had an unusually large amount of extension headers, it is possible that the upper-layer protocol type may not be present in the ICMPv6 message, due to truncation of the original packet to meet the minimum IPv6 MTU [IPv6] limit. In that case, the error message is silently dropped after any IPv6-layer processing. That's not SHOULD, it's MUST. (And RFC 2460 "Internet Protocol, Version 6 (IPv6) Specification" says, in section 5: 5. Packet Size Issues IPv6 requires that every link in the internet have an MTU of 1280 octets or greater. On any link that cannot convey a 1280-octet packet in one piece, link-specific fragmentation and reassembly must be provided at a layer below IPv6. so one cannot excuse the lack of any invoking message information by saying putting any there would make the ICMPv6 packet bigger than the minimum IPv6 MTU, as the offending packets were *well* under that limit.)
