[Michele Bustos <mbustos@xxxxxxxxxxx>]

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:guy@xxxxxxxxxx]
Sent: Thursday, October 31, 2002 11:42 AM
To: Michele Bustos
Cc: 'ethereal-users@xxxxxxxxxxxx'
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.)