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



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!"



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

Reply via email to