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
Perry Lorier <[EMAIL PROTECTED]> wrote:
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 j! ust
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
--------------------------------------------------------------------
-------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
