Re: [Lsr] [Technical Errata Reported] RFC5340 (7649)

[Alexander Okonnikov <[e-mail]>]

Hi WG,

Regarding the errata - the errata claims that cause of it is the bug in an implementation, sending DBD with Interface MTU = 0. Maybe it is so, but it seems that real bug is in implementation(s), receiving and dropping such DPD.

Both RFCs - 5838 and 5340 - inherit rules for receiving DBD from RFC 2328. RFC 2328 says follow (section 10.6):

"... If the Interface MTU field in the Database Description packet indicates an IP datagram size that is larger than the router can accept on the receiving interface without fragmentation, the Database Description packet is rejected. ..."

Obviously, 0 is not larger than IP datagram size that can be accepted on the receiving interface. I guess that the size is greater than 0, but, even if it is equal to 0, then 0 (Interface MTU value in DBD) is not larger than 0 (acceptable size of receiving datagram).

Also, RFC 5838 contains (section 2.7) incorrect rephrasing of RFC 2328:

"... As specified in Section 10.6 of [OSPFV2], the Database Description packet will be rejected if the MTU is greater than the receiving interface's MTU for the address family corresponding to the instance. ..."

"Is larger than the router can accept on the receiving interface" (RFC 2328) and "is greater than the receiving interface's MTU" (RFC 5838) - strictly speaking, two ones are not the same. My understanding of goal of the procedure in section 10.6 of RFC 2328 is to ensure that lower layer maximum receive unit value (Maximum Receive Unit in PPP, Maximum Frame Size in IEEE 802.3, and so on) is enough to accept IP datagrams with size, specified in Interface MTU of DBD message (of course, with needed math for corresponding lower layer encapsulations), such that there would not be blackholing on lower layer on receipt. I don't see reason to check Interface MTU from DBD against MTU of receiving interface. MTU of receiving interface is not the same as MRU of receiving interface, and MTU of the interface is irrelevant to receiving datagrams.

RFC 1812 says follow in section 3.3.4:

"... However, a router SHOULD be willing to receive a packet as large as the maximum frame size even if that is larger than the MTU. ..."

It is common that for regular interfaces MRU usually eqauls to MTU. But for tunnels this equality doesn't hold, due to, e.g. assymetric routing. And even for regular interfaces, while MRU=MTU usually, strictly speaking two ones are not have to be equal.

By the way, "without fragmentation" in 10.6 of RFC 2328 looks unclear for me. I'm not aware about fragmentations performed on receiving, and do you? Either this phrase inapplicable for receiving IP datagrams, or, probably, 'without reassembly' was assumed there?

Now regarding essense of the problem. I don't agree with the errata - it is clear enough that 'virtual links' are mentioned in context of OSPF, hence, 'OSPF virtual links' rather than some other 'virtual links' or 'IP virtual links' are implied there. But, I think that decision taken in the subjected implementation is good trade-off for tunnel interfaces, which doesn't violate procedure for receiver side, and, thus, even doesn't require implementation of 'ignore-mtu' functionality on receiving side. Actually, issues, related to path MTU discovery nature and applicable to OSPF virtual links, are equally applicable to OSPF interfaces deployed as tunnels. I don't see how DBD Interface MTU can help in solving problems with possible fragmentation, PMTU blackholes on transit and so on. My view is that actual problem, which DBD Interface MTU is intended to mitigate, is on tunnel egress OSPF router. Due to nature of tunnels, tunneled IP datagrams can ingress OSPF router via any of multiple transport interfaces, each of which may have its own MRU. What will be MRU of tunnel interface in this case? It is OK if all those transport interfaces have the same MRU value, and tunnel interface MRU will be stable, but what if it is not the case? We would need to adjust tunnel MRU every time some transport interface added/removed. It seems that omitting MRU check via DBD Interface MTU for tunnel interfaces would be more or less good solution which doesn't require OSPF spec modification (beside writing '0' into Interface MTU field). Any way, current OSPF (per my knowledge) doesn't provide mechanism for OSPF DBD receiver to signal actual MRU to OSPF DBD sender, and thus rejecting DBD on receive doesn't look better than broken PMTUD (PMTUD blackhole).

Sorry in advance for long complicated speech.

Thanks.

> 21 сент. 2023 г., в 12:49, Acee Lindem <[e-mail]> написал(а):
> 
> 
> 
>> On Sep 20, 2023, at 7:02 PM, Owen DeLong <[e-mail]> wrote:
>> 
>> Given what I have seen, I would argue for semantics of 0=valid only on virtual link. On others, must not be 0 and must reflect actual interface MTU.
> 
> If you feel further specification is necessary, it should be done in a draft rather than an Errata (as John already mentioned). However, note that this is a solved problem as most vendors have implemented the “ip ospf ignore-mtu” interface configuration. 
> 
> Thanks,
> Acee
> 
> 
> 
>> 
>> Owen
>> 
>> 
>>> On Sep 20, 2023, at 12:34, Tony Przygienda <[e-mail]> wrote:
>>> 
>>> errata is _not_ precise enough and the errata as proposed will cause more problems than it solves from my experience 
>>> 
>>> 1. what is the semantics of 0 here? Don't care? Then 0 can be sent on tunnel MTU and tunnel must stay up if one side sends "don't care"? If semantics of 0 is "no value"  then same consideration applies AFAIS. So the errata would need to say "0 is a reserved value that means in ospf virtual link case that the field is not semantically valid and in other cases represents value of 0" (which seems nonsensical a bit but seems to aim towards what the errata tries to say) 
>>> 2. fragmenting/non-fragmenting tunnels need be considered and explained in the errata. GRE can optionally fragment (but not in v6 case AFAIR except optionally for some wild header cases). In case of IPv6 we have additionally the 1280 consideration on top AFAIR so if parts of the network runs bigger MTU, GRE does NOT fragment and more than 1280 shows up we end up with fragmented network IGP wise possibly. And I didn't even start to talk about extension headers on which the RFC is really quiet about  ;-) 
>>> 3. the MTU "largest datagram" needs to be errate'd to something more precise on top. Is that _with_ tunnel headers, with/without tunnel encaps etc (observe that e.g. vxlan is really an ip in ip and then ospf could be carried in that) or _purely_ the OSPF IPv6 packet? 
>>> 
>>> we fought those problems in ISIS forever with ugly corner cases (PPoE) I need to explain every couple of years to another batch of system engineers .
>>> 
>>> I personally strongly suggest from experience to say "0 value" semantics is everywhere a "don't care" value which implicitly does remove MTU mismatch considerations in all kinds of interesting, ugly deployment cases. Other option is that to mean "same value as set on my interface" or "default value the protocol has set as constant" (in rift we chose that route from experience but we were driven by strong ZTP requirements) 
>>> 
>>> And BTW, any hardened stack has "ignore-mtu-mismatch" since this is a pretty common case to find implementations advertising mismatched values in weird tunnel/encaps cases (VLAN taggin' cases are a classic culprit beside PPoE IME) and stuff gets knob'ed out then ... 
>>> 
>>> that's of top of my head here ... 
>>> 
>>> -- tony  
>>> 
>>> On Wed, Sep 20, 2023 at 8:06 PM Acee Lindem <[e-mail]> wrote:
>>> I’m beginning to get a feeling of Deja MTU… 
>>> 
>>> Acee
>>> 
>>>> On Sep 19, 2023, at 19:15, RFC Errata System <[e-mail]> wrote:
>>>> 
>>>> The following errata report has been submitted for RFC5340,
>>>> "OSPF for IPv6".
>>>> 
>>>> --------------------------------------
>>>> You may review the report below and at:
>>>> https://www.rfc-editor.org/errata/eid7649
>>>> 
>>>> --------------------------------------
>>>> Type: Technical
>>>> Reported by: Owen DeLong <[e-mail]>
>>>> 
>>>> Section: A.3.3 (in part)
>>>> 
>>>> Original Text
>>>> -------------
>>>> Interface MTU
>>>>     The size in bytes of the largest IPv6 datagram that can be sent
>>>>     out the associated interface without fragmentation.  The MTUs of
>>>>     common Internet link types can be found in Table 7-1 of [MTUDISC].
>>>>     Interface MTU should be set to 0 in Database Description packets
>>>>     sent over virtual links.
>>>> 
>>>> 
>>>> Corrected Text
>>>> --------------
>>>> Interface MTU
>>>>     The size in bytes of the largest IPv6 datagram that can be sent
>>>>     out the associated interface without fragmentation.  The MTUs of
>>>>     common Internet link types can be found in Table 7-1 of [MTUDISC].
>>>>     Interface MTU should be set to 0 in Database Description packets
>>>>     sent over OSPF virtual links. This rule should not be applied to tunnel
>>>>     or other software interfaces.
>>>> 
>>>> Notes
>>>> -----
>>>> OSPF Virtual links carry only OSPF packets so MTU negotiation is not needed and this provision makes sense. For interfaces that have an actual MTU, even though they may be "virtual" interfaces, they are not "virtual links" in the intended meaning of this paragraph. As such, this change will provide clarification and remove ambiguity from the current standard. At least one popular router vendor implements this RFC as MTU = 0 sent on all GRE interfaces which results in incompatibilities with most other router platforms which expect an actual value. The router vendor points to this provision in the RFCs as justification for their implementation. It is (arguably) a legitimate, if nonsensical interpretation of the existing text.
>>>> 
>>>> Instructions:
>>>> -------------
>>>> This erratum is currently posted as "Reported". If necessary, please
>>>> use "Reply All" to discuss whether it should be verified or
>>>> rejected. When a decision is reached, the verifying party  
>>>> can log in to change the status and edit the report, if necessary. 
>>>> 
>>>> --------------------------------------
>>>> RFC5340 (draft-ietf-ospf-ospfv3-update-23)
>>>> --------------------------------------
>>>> Title               : OSPF for IPv6
>>>> Publication Date    : July 2008
>>>> Author(s)           : R. Coltun, D. Ferguson, J. Moy, A. Lindem
>>>> Category            : PROPOSED STANDARD
>>>> Source              : Open Shortest Path First IGP
>>>> Area                : Routing
>>>> Stream              : IETF
>>>> Verifying Party     : IESG
>>>> 
>>>> _______________________________________________
>>>> Lsr mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/lsr
>>> 
>>> _______________________________________________
>>> Lsr mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/lsr
>> 
> 
> _______________________________________________
> Lsr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/lsr