RFC Errata
Found 1 record.
Status: Rejected (1)
RFC 5838, "Support of Address Families in OSPFv3", April 2010
Note: This RFC has been updated by RFC 6969, RFC 7949, RFC 8362, RFC 9454
Source of RFC: ospf (rtg)
Errata ID: 7644
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Owen DeLong
Date Reported: 2023-09-17
Rejected by: John Scudder
Date Rejected: 2024-01-11
Section 2.7 says:
Interface MTU The size in octets of the largest address family specific datagram that can be sent on the associated interface without fragmentation. The MTUs of common Internet link types can be found in Table 7-1 of [MTUDISC]. The Interface MTU SHOULD be set to 0 in Database Description packets sent over virtual links.
It should say:
Interface MTU The size in octets of the largest address family specific datagram that can be sent on the associated interface without fragmentation. The MTUs of common Internet link types can be found in Table 7-1 of [MTUDISC]. The Interface MTU SHOULD be set to 0 in Database Description packets sent over (OSPF3) virtual links. This recommendation MUST NOT be applied to tunnel and other virtual or software interfaces which carry traffic other than OSPF protocol packets.
Notes:
Currently, the language is ambiguous and at least one vendor has implemented OSPF3 sending an MTU of zero on GRE interfaces (and possibly others such as IPIP, IPSEC, etc., as I have not tested these). I believe that the intent of the RFC is to refer strictly to OSPF virtual-links which carry only OSPF protocol data and therefore have no meaningful MTU. When this is mistakenly applied to other forms of "virtual" interfaces such as tunnels, the results can be quite harmful.
As such, I think that clarification is in order, since the vendor in question is unrepentant and claims their current implementation to be compliant with the RFC.
--VERIFIER NOTES--
See discussion at https://mailarchive.ietf.org/arch/msg/lsr/wXdOtU9H2vIoA1xs10xZ4oh8bwU/