Hi, all, > On May 21, 2020, at 12:30 PM, Alexandre Petrescu > <[email protected]> wrote: > >> For AX.25 version 2.0, the >> maximum frame size expected is 330 bytes and implementations MUST be >> prepared to handle frames of this size. Higher frame sizes can be >> negotiated by AX.25 version 2.2 and so this is a minimum requirement >> and not a limit. > > It is ok. For IPv6, the minimum MTU (minimum Maximum Transmission Unit) is > 1280 bytes.
There are several maximums that are relevant - path MTU is only one of them, and not necessarily the one that is relevant here. For this protocol, all you really care about is EMTU_S (as defined in RFC1122 - see draft-ietf-intarea-tunnels, which admittedly needs to be refreshed in ample spare time). For IPv6, this is 1500; for IPv4 it is 576. Those are more than sufficient if you aren’t significantly affected by packet loss per se, which *can* be amplified by source fragmentation, but that might not be relevant in this case. If you want to talk about performance under certain losses where fragmentation causes a known problem, you should add an additional suggestion to do path MTU discovery (PLPMTUD - which you SHOULD really build in if it isn’t there yet), because otherwise you’re stuck with the path mins of 1280 for IPv6 and (sorry, still) 64 for IPv4. > For IPv4, it is not worth mentioning. One, including myself, would go as far > as suggesting to remove the IPv4 keyword from the draft altogether. Although I agree all new drafts need to address IPv6, it’s naive to ignore IPv4 - especially for a protocol such as this, which is, if anything, more likely to operate using legacy equipment. Joe
_______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
