Subject: Re: Validation of Packet Too Big Payload using Echo Request

From: Timothy Winters <[email-masked]>
Date: Tue, 28 Jan 2020 08:39:10 -0500

On Tue, Jan 28, 2020 at 3:10 AM <[email-masked]> wrote:

> > The IPv6 Ready Logo Committee updated testing to include a test for
> validating the Packet Too Big message content based on the following part
> of 8201.
> >
> > "Nodes should appropriately validate the payload of ICMPv6 PTB
> >    messages to ensure these are received in response to transmitted
> >    traffic (i.e., a reported error condition that corresponds to an IPv6
> >    packet actually sent by the application) per [ICMPv6]."
> >
> > I've included the steps below used to verify the IPv6 implementation
> validates the Packet Too Big.
> >
> > Step
> > Action
> > Expected Behavior
> > 1.
> > TR1 forwards an Echo Request from TN2 to the NUT.  The packet size is
> 1500 octets.
> > The NUT should respond without fragmenting the packet to the Echo
> Request using TR1 as a first hop.
> > 2.
> > TR1 transmits a Packet Too Big message to the NUT with an ICMPv6
> Identifier does not match the Echo Reply in Step 1.
> >
> > 3.
> > TR1 forwards an Echo Request from TN2 to the NUT.  The packet size is
> 1500 octets.
> > The NUT should respond without fragmenting the packet to the Echo
> Request using TR1 as a first hop.
> >
> > We received a comment that this validation shouldn't apply to ICMPv6 and
> it should only apply to TCP or protocols that have state.   Do we think
> this only applies to TCP or is it valid for all traffic?
>
> RFC8201 is a network layer mechanism, and the paragraph above applies to
> all packets sent by the node. Regardless of transport layer protocol.
>
Thanks for the replies that's my opinion as well.  We'll leave it as
documented.

~Tim

> Best regards,
> Ole

---

From: Ole Troan <[email-masked]>
Date: Tue, 28 Jan 2020 14:58:04 +0100

> On 28 Jan 2020, at 14:39, Timothy Winters <[email-masked]> wrote:
> 
>> 
>> RFC8201 is a network layer mechanism, and the paragraph above applies to all packets sent by the node. Regardless of transport layer protocol.
> Thanks for the replies that's my opinion as well.  We'll leave it as documented.

Then we can argue of course argue over how easy this is to implement in the different cases...

Cheers 
Ole

---

From: 神明達哉 <[email-masked]>
Date: Thu, 30 Jan 2020 14:07:38 -0800

At Mon, 27 Jan 2020 11:39:58 -0800,
Fred Baker <[email-masked]> wrote:

> PTB and PMTU activates in IPv4 applies to streams of packets, not
> sessions. Given that IPv6 operates from the same definitions, I
> don't see why it would be applied to something different in IPv6.

> Now, in fairness, TCP has a way to address PTB/PMTU - it changes the
> MSS in use for a session. UDP doesn't have anything so clear. But
> IMNSHO, that is a deficiency in UDP, not in ICMP. UDP, or the
> process using it, is informed of the limitation. It fails to act on
> it.

We can still fragment the subsequent UDP packets at the known PMTU (I
know everyone hates IP fragmentation but that's a different topic).
In my understanding PMTUD work less well with UDP application than TCP
apps because UDP apps tend to be "connectionless" (e.g. using
non-connected UDP sockets) and the OS's ICMP layer often doesn't like
to adjust its behavior upon receiving a packet too big error when it
cannot find an application that matches the src-dst pair specified in
the ICMP error (which is not the case for connectionless UDP apps).

BTW, RFC3542 provides a way to let UDP apps (even connectionless ones)
know the change of the path MTU that may affect those applications,
although I suspect RFC3542 in general, let alone this particular
option, is not so widely implemented.

Maybe an offtopic for this thread anyway, though.

--
JINMEI, Tatuya