PMTU_MTUTooBig.seq - ICMP Packet Too Big message is received with MTU larger than current MTU
To check that if ICMP Packet Too Big message is received with MTU larger
than current MTU, the endpoint should ignore the ICMP Packet Too Big
message.
./PMTU_TooBig.seq [-tooloption ...] -pkt ./PMTU_TooBig.def
-tooloption : v6eval tool option
See Also: ../common/STD_PKT_COMMON.def
../common/SCTP_COMMON.def
Association established between endpoint A and B. Also arrange the
data in endpoint A such that ICMP Packet Too Big message with MTU
larger than current MTU is sent to endpoint A.
Endpoint A Endpoint B ULP
(ESTABLISHED) (ESTABLISHED)
ICMP ----------------->
(Packet Too Big)
DATA ----------------->
(Segment 1)
<----------------- SACK
(Segment 1)
DATA ----------------->
(Segment 2)
<----------------- DATA
(Segment 1)
SACK ----------------->
<----------------- DATA
(Segment 2)
SACK ----------------->
TEST DESCRIPTION:
1. Send ICMP Packet Too Big message from endpoint A to B with MTU
larger than current MTU.
2. Send DATA message from endpoint A to B with data size larger
than current MTU in two segments and endpoint B will send back
that DATA message.
3. Check A: PMTU of endpoint B is not changed, DATA message can
be received at endpoint A, and it is fragment by current MTU.
ICMPv4 Fragmentation Needed message with MTU larger than current
MTU will cause PMTU be set to 1492.
RFC 4960
Appendix C. ICMP Handling
Whenever an ICMP message is received by an SCTP endpoint, the
following procedures MUST be followed to ensure proper utilization of
the information being provided by layer 3.
ICMP1) An implementation MAY ignore all ICMPv4 messages where the
type field is not set to "Destination Unreachable".
ICMP2) An implementation MAY ignore all ICMPv6 messages where the
type field is not "Destination Unreachable", "Parameter
Problem",, or "Packet Too Big".
ICMP3) An implementation MAY ignore any ICMPv4 messages where the
code does not indicate "Protocol Unreachable" or
"Fragmentation Needed".
ICMP4) An implementation MAY ignore all ICMPv6 messages of type
"Parameter Problem" if the code is not "Unrecognized Next
Header Type Encountered".
ICMP5) An implementation MUST use the payload of the ICMP message (v4
or v6) to locate the association that sent the message to
which ICMP is responding. If the association cannot be found,
an implementation SHOULD ignore the ICMP message.
ICMP6) An implementation MUST validate that the Verification Tag
contained in the ICMP message matches the Verification Tag of
the peer. If the Verification Tag is not 0 and does NOT
match, discard the ICMP message. If it is 0 and the ICMP
message contains enough bytes to verify that the chunk type is
an INIT chunk and that the Initiate Tag matches the tag of the
peer, continue with ICMP7. If the ICMP message is too short
or the chunk type or the Initiate Tag does not match, silently
discard the packet.
ICMP7) If the ICMP message is either a v6 "Packet Too Big" or a v4
"Fragmentation Needed", an implementation MAY process this
information as defined for PATH MTU discovery.
ICMP8) If the ICMP code is an "Unrecognized Next Header Type
Encountered" or a "Protocol Unreachable", an implementation
MUST treat this message as an abort with the T bit set if it
does not contain an INIT chunk. If it does contain an INIT
chunk and the association is in the COOKIE-WAIT state, handle
the ICMP message like an ABORT.
ICMP9) If the ICMPv6 code is "Destination Unreachable", the
implementation MAY mark the destination into the unreachable
state or alternatively increment the path error counter.
Note that these procedures differ from [RFC1122] and from its
requirements for processing of port-unreachable messages and the
requirements that an implementation MUST abort associations in
response to a "protocol unreachable" message. Port-unreachable
messages are not processed, since an implementation will send an
ABORT, not a port unreachable. The stricter handling of the
"protocol unreachable" message is due to security concerns for hosts
that do NOT support SCTP.