On Mon, Oct 27, 2025 at 9:42 AM Bill Fenner <[email protected]> wrote: >> >> And I would assume that basic MTU & fragmentation consideration should be >> >> added.
>> > Good point regarding the MTU; I lean towards prohibiting insertion. >> >> I assume this excludes RFC7915 cases, right? > RFC7915 doesn't talk about ways in which we might change the message and how > to avoid violating the MTU Section 4 (and, more specifically, section 4.2) does. It covers the case of IPv4->IPv6 translation. >, so I think that has to be addressed in this document. To be honest, I'm not even sure that the RFC7915 translator can be considered as 'an intermediate node inserting a field'. IMHO, the translator is creating a new packet. What I'd suggest is to separate translation and insertion cases. For translation the draft, IMHO, should leave the details to draft-ietf-v6ops-icmpext-xlat-v6only-source (as it already updates RFC7915 to use this extension). The draft could just say smth like "IP/ICMP Translators [RFC7915] MAY use those extensions as described in draft-ietf-v6ops-icmpext-xlat-v6only-source". (It would join our documents into a cluster though, not sure if you are OK with that) draft-ietf-v6ops-icmpext-xlat-v6only-source should be out of the WGLC today - I'd appreciate your review. Maybe we need to say more about MTU there? The Appendix section provides some guidance but maybe it should be more explicit in the RFC7915-update section? Does it make sense? Then we can talk about all other cases of insertions (which are currently not defined and are outside of scope). > So this is either SHOULD NOT or MUST NOT insert the bits if it causes the > ICMP message to exceed the MTU? > > Or, SHOULD or MUST fragment the ICMP message if insertion of the bits causes > the message to exceed the MTU? > > Should the rules be the same for IPv4 and IPv6, or different? "If an intermediate node adds a Node Identification Object to an ICMPv6 packet and the resulting packet exceeds the minimum IPv6 MTU (1280 bytes), the node MUST truncate the embedded invoking packet by removing the trailing octets to keep the packet size equal to 1280 bytes. The node MUST update the length field of the ICMP message accordingly. A node performing such insertion SHOULD have a configuration option to adjust the threshold of the minimum IPv6 MTU to reflects the real value of the minimum IPv6 MTU in the network (greater than 1280 bytes)" (similar to RFC7915) (Not sure if we need to cover the case when such truncation reduces the invoking packet part below 128 bytes? In that case, I guess, smth like "MUST NOT insert"? For IPv4 I do not have a strong preference but I'd suggest the same idea of truncation. >> So we are talking about >> more text to Section 4 to discuss insertion by intermediate nodes >> which are not translating between protocols? > > > I think whatever we add has to be applicable to anyone who inserts an > extension to a message in progress. > >> > In a previous age I would have said SHOULD NOT insert if it results in the >> > new packet exceeding the MTU, and let it be obvious that if you want to do >> > it you have to deal with the consequences of fragmentation; now that >> > you've pointed out the IESG statement I'm more inclined to say MUST NOT >> > because I don't want to get into the details. >> >> It is only possible to append that object to a very limited list of >> error messages. >> I do not think we want an ICMP error message to get fragmented, so >> clearly intermediate nodes MUST NOT insert the structure if the >> resulting packet exceeds min. MTU for the given protocol family. >> (Practically it means it's impossible to do insertion for IPv4...) > > > Well, it can't really be IPv4 minimum MTU, since RFC4884 says you have to > include 128 bytes of the original packet, which already blows past the > minimum MTU, but maybe 576. > > So, is the text > > The extension MUST NOT be inserted if it causes an ICMPv4 message to grow > beyond the <words that mean 576> or an ICMPv6 message to grow beyond <words > that mean 1280>. > > appropriate? I guess <words that mean 1280> is "IPv6 minimum MTU"; what words > mean 576? "IPv4 minimum reassembly buffer"? > > Should this be SHOULD NOT with the escape clause that if you know via some > out-of-band mechanism that the path from you to the receiver of the ICMP > message has a sufficient MTU that you can send it anyway? > > Bill > -- Cheers, Jen Linkova _______________________________________________ Int-area mailing list -- [email protected] To unsubscribe send an email to [email protected]
