Subject: IPv6 WG Last Call:draft-ietf-ipngwg-icmp-v3-05.txt

From: Brian Haberman <[email-masked]>
Date: Mon, 25 Oct 2004 10:41:45 -0400

All,
      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)	: A. Conta, et al.
	Filename	: draft-ietf-ipngwg-icmp-v3-05.txt
	Pages	: 26
	Date		: 2004-10-22

at Draft Standard.  This LC is aimed at ensuring resolution of all
issues raised during the previous last call.  Substantive comments
should be directed to the mailing.  This last call will end on 
11/01/2004.

Regards,
Bob & Brian

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Fred Templin <[email-masked]>
Date: Mon, 25 Oct 2004 10:38:49 -0700 (PDT)

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 current list as follows:
 
    3 - unspecified data corruption encountered
 
Note that in this case, the Pointer might point to a byte offset in the
packet body beyond the end of the IPv6 header and header extensions.
The Description text should therefore also be re-worded slightly to allow
for this fact as follows:

   "If an IPv6 node processing a packet finds a problem such that it cannot
   complete processing the packet, it MUST discard the packet and SHOULD
   send an ICMPv6 Parameter Problem message to the packet's source,
   indicating the type and location of the problem.

   The pointer identifies the octet of the original packet where the error was
   detected.  For example, an ICMPv6 message with Type field = 4, Code
   field = 1, and Pointer field = 40 would indicate that the IPv6 extension
   header following the IPv6 header of the original packet holds an
   unrecognized Next Header field value."

Fred L. Templin
[email-masked]

Brian Haberman <[email-masked]> wrote:
All,
This is the start of a 1-week IPv6 working group last call for
recycling:

Regards,
Bob & Brian

> ATTACHMENT part 1.2 application/pkcs7-signature name=smime.p7s

---

From: Pekka Savola <[email-masked]>
Date: Wed, 27 Oct 2004 19:39:07 +0300 (EEST)

Hi,

On Mon, 25 Oct 2004, Brian Haberman wrote:
> should be directed to the mailing.  This last call will end on 11/01/2004.

I think it was forgotten to clarify the ICMPv6 rate-limiting language 
(at the very least, using 'originate' instead of 'send') based on the 
consensus called at:

http://www.ietf.org/mail-archive/web/ipv6/current/msg03539.html

One attempt by me to fix this was at:

http://www.ietf.org/mail-archive/web/ipv6/current/msg03421.html

Other than that, I think the doc should be fine.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Pekka Savola <[email-masked]>
Date: Wed, 27 Oct 2004 19:43:27 +0300 (EEST)

>    3 - unspecified data corruption encountered

FWIW, I don't think this should be added, remembering that we're 
recycling at DS, because:
  1) there doesn't seem to be clear need for it in this spec, and
  2) if some other spec needs it, it can just define it

(Because the packets whose ICMP checksum is incorrect are silently 
discarded, and there is no checksum for the data payload, I can't 
figure how ICMPv6 could notice any further data corruption in any 
case, so I see no direct justification in *this* spec.)

---

From: Fred Templin <[email-masked]>
Date: Wed, 27 Oct 2004 10:15:06 -0700 (PDT)

Pekka Savola <[email-masked]> 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 error message with the new
Parameter Problem code back to the source. Data corruption can be detected,
e.g., if the link layer has a way to inform the IPv6 layer of packets received with
errors - but this is not necessarily the *only* example.
 
Fred
[email-masked]

---

From: Pekka Savola <[email-masked]>
Date: Wed, 27 Oct 2004 20:27:13 +0300 (EEST)

> errors - but this is not necessarily the *only* example.

OK.  Are there link layer specifications which do this?  And if so, 
are there implementations that do that?

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.

---

From: Fred Templin <[email-masked]>
Date: Wed, 27 Oct 2004 10:59:06 -0700 (PDT)

Pekka Savola <[email-masked]> 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 reception of packets with data corruption could be an indication
of congestion, in which case link-layer retransmit might not be the best thing.
Also, silent discard would miss out on an opportunity to provide congestion
feedback to the source whereas the ICMPv6s with the new parameter
problem code could be used to provide the necessary feedback.
 
Fred
[email-masked]

---

From: Perry Lorier <[email-masked]>
Date: Thu, 28 Oct 2004 10:42:56 +1300

>errors - but this is not necessarily the *only* example.
I may be rather naive here, but if you detect that the packet is corrupt 
then how do you know if the source address is valid?  How is the remote 
end supposed to tie it back to a packet it sent given that you've just 
said "this packet is corrupt, and you can't rely on any data in it"?

While I agree that something like TCP would love to know if loss was due 
to transmission error, or due to congestion, I don't see how TCP could 
reliably deal with a packet that says "A packet you, (or someone else) 
sent that may have been from this protocol (or some other protocol, we 
dunno), with ports that might be a  and b (but could equally be any 
other port), was corrupt.  Good luck!"

---

From: Fred Templin <[email-masked]>
Date: Wed, 27 Oct 2004 15:18:29 -0700 (PDT)

It wasn't specified, but the IPv6 layer should have reasonable assurance that
the corruption occurred beyond the end of the header before sending ICMPs.
 
Fred
[email-masked]

Perry Lorier <[email-masked]> wrote:
Fred Templin wrote:

>Pekka Savola