0

I have asked one question already related what is the purpose of payload in Packet Too Big ICMPv6 message. why_PTB_payload

As per the latest IPv6 logo certification I have came across this test case where a sender send ICMPV6 echo request message to destination having some routers in between and the receiver (destination) received the echo request. then,

  1. Receiver send ICMPv6 echo reply but got ICMPV6 packet too big message from router in between with wrong/forged echo reply header appending to the (PTB) packet too big message as a payload. (Deliberately sending wrong payload).

  2. Again the ICMPv6 echo request sent by the sender, now the receiver start fragmenting the echo reply because of the above step1 (i.e without validating the PTB payload the Receiver changed it's MTU value).

According to the test case we should not change the MTU on receiving the wrong or forged payload on PTB message (payload will be the original packet that cannot be forwarded due to less Path MTU)

But this look unnecessary work to validate the PTB for echo reply and seems no proper use-case, this test case look invalid to me as we never store the state of echo reply sent by the kernel to validate the PTB in case PTB carry the wrong ICMPv6 reply header on it's payload.

If this is the valid case then I want to know the logic how we can implement this or if not then why this test case is even there at the IPV6 logo certification.

Link to the document containing the test case IPv6LogoCertificationTestCases (Test case number v6LC.4.1.12)

Aryaman Gupta
  • 616
  • 1
  • 8
  • 20
  • It is all to facilitate PMTUD. IPv6 cannot fragment packets in the path the way IPv4 can, so it is required to perform PMTUD. Some people simply set the IPv6 MTU to the minimum allowed in the path (1280) to avoid PMTUD. – Ron Maupin Jan 27 '20 at 11:02
  • @RonMaupin you are telling right thing but that's not my question. I want to know why to validate the payload of an echo reply not get sent to the destination because of lesser path MTU. I got this from the RFC 8021 – Aryaman Gupta Jan 27 '20 at 15:30
  • Point 1 Many implementations fail to perform validation on ICMP error ,It should be noted that in some cases, such as when an ICMPv6 error message has (supposedly) been elicited by a connectionless transport protocol (or some other connectionless protocol being encapsulated in IPv6), it may be virtually impossible to perform validation checks on the received ICMPv6 error message. And, because of IPv6 extension headers, the ICMPv6 payload might not even contain any useful information on which to perform validation checks. – Aryaman Gupta Jan 27 '20 at 15:36
  • Point 2 Upon receipt of one of the aforementioned ICMPv6 PTB error messages, the Destination Cache [RFC4861] is usually updated to reflect that any subsequent packets to such a destination should include a Fragment Header. This means that a single ICMPv6 PTB error message might affect multiple communication instances (e.g., TCP connections) with such a destination. – Aryaman Gupta Jan 27 '20 at 15:37
  • The current, modern OSes perform the PMTUD for you, and you should not even need to worry about it unless you want to bypass the slight delay it imposes byt simply setting the IPv6 MTU to 1280. – Ron Maupin Jan 27 '20 at 15:39
  • @RonMaupin I have to implement this test case on our current freebsd11 based OS, for IPV6 logo certification but I am not able to understand the actual use case of this test case or the logic to implement. And if we do not handle this test case then our product will not be ipv6 compliant. – Aryaman Gupta Jan 27 '20 at 15:46
  • 1
    It is testing that your OS will not accept incorrect or faked information to adjust its MTU. Understand that there are legitimate cases where you have asymmetric routing (very common), and the MTU in the return path will be different, so you must take that into account and adjust the MTU for such cases, but you need to protect against invalid messages. – Ron Maupin Jan 27 '20 at 15:54

0 Answers0