Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of
ext Tim Hartrick
Sent: Wednesday, October 27, 2004 4:12 PM
To: Fred Templin
Cc: Brian Haberman; IPv6 WG; Pekka Savola; Perry Lorier
Subject: Re: IPv6 WG Last Call:draft-ietf-ipngwg-icmp-v3-05.txt
All,
On Wed, 2004
Of
ext Pekka Savola
Sent: Wednesday, October 27, 2004 9:39 AM
To: Brian Haberman
Cc: IPv6 WG
Subject: Re: IPv6 WG Last Call:draft-ietf-ipngwg-icmp-v3-05.txt
Hi,
On Mon, 25 Oct 2004, Brian Haberman wrote:
This is the start of a 1-week IPv6 working group last call for
recycling
Hi,
On Mon, 25 Oct 2004, Brian Haberman wrote:
This is the start of a 1-week IPv6 working group last call for
recycling:
Title : Internet Control Message Protocol (ICMPv6)for the
Internet Protocol Version 6 (IPv6) Specification
Author(s)
Pekka Savola [EMAIL PROTECTED] wrote:
I can't figure how ICMPv6 could notice any further data corruption in any case, so I see no direct justification in *this* spec.)
We are speaking here about the case of the IPv6 layer noticing data corruption
in a received packet and then sending an ICMPv6
Pekka Savola [EMAIL PROTECTED] wrote:
I have no doubt that there may be link-layers which might detect or be able to detect corruption. But the typical approach then, AFAICS, is either to silently discard packet, or to try to retransmit at link-layer if there was a link-layer problem.
Persistent
Fred Templin wrote:
Pekka Savola [EMAIL PROTECTED] wrote:
I can't figure how ICMPv6 could notice any further data corruption in any
case, so I see no direct justification in *this* spec.)
We are speaking here about the case of the IPv6 layer noticing data corruption
in a received packet and
I would like to see a new Code added to the Parameter Problem Message
Type ([ICMPv6], section 3.4) whereby the end host or a router on the path
can inform the source that unspecified data corruption was encountered
in the packet. The code definition should appear as a new item at the
end of the
