Hi, all,
On 22. Mar 2021, at 07:42, <mohamed.boucadair@xxxxxxxxxx> <mohamed.boucadair@xxxxxxxxxx> wrote:
Hi Michael,
Thank you for the review.
The motivation was used as it was the key element in the discussion in Section 3.3.3 of RFC1122, but you made a fair comment.
==
DISCUSSION:
Picking the correct datagram size to use when sending data
is a complex topic [IP:9].
(a) In general, no host is required to accept an IP
datagram larger than 576 bytes (including header and
data), so a host must not send a larger datagram
without explicit knowledge or prior arrangement with
the destination host.
==
We can update the text as follows:
OLD:
assume a PMTU of 576 bytes for IPv4 datagrams, as every IPv4 host
must be capable of receiving a packet whose length is equal to 576
bytes as discussed in [RFC0791] and [RFC1122].
NEW:
assume a PMTU of 576 bytes for IPv4 datagrams (see Section 3.3.3 of [RFC1122]).
Hi Med, let me try to get my point clear: You can use Section 3.3.3 of [RFC1122] to motivate that the sender shou not send datagram larger than 576, since there is no guarantee that the receiver has resources to reassemble and process it. But RFC 1122 makes no statement about the path. As far as I know there is no safe value for a PMTU you can derive from a specification. So maybe: NEW: assume a PMTU of 576 bytes for IPv4 datagrams (see Section 3.3.3 of [RFC1122] for support at the receiver).
I agree with the assumption, but Sec 3.3.3 is not entirely clear about it being a *path* MTU, rather than EMTU_R.
Joe
Joe
|
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
