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.)
