Choose conservatively when interface budgets vary

For a packet-to-packet varying interface, use of its smallest effective MTU is a SHOULD, not an unconditional MUST.

• RFC 6691 section 5.2 says TCP SHOULD use the smallest effective MTU of a varying interface to calculate its advertised MSS. RFC 9293 section 3.7.3 retains this recommendation as SHLD-6.
• The example IPv6 interface alternates between effective packet budgets 1500 and 1280. Choosing only 1500 would suggest MSS 1440; a full-sized no-options packet would then exceed the 1280 state.
• Choosing the smaller effective MTU 1280 gives 1220 after the 40-byte IPv6 base header and 20-byte TCP base header. That leaves room for a no-options packet in either illustrated interface state.
• Actual additional headers still reduce data per packet: with 20 extra-header bytes,1220 −20 =1200 data bytes. The advertised 1220 does not itself shrink each time options change.
• Exception outside these ordinary examples: RFC 6691 section 5.3 discusses IPv6 jumbograms. Under RFC 2675, an MSS value 65535 has special infinity semantics; it is not a universal literal 65535-byte data cap. Path MTU Discovery determines the actual limit.

The two budgets are fictional inputs, not a model of ROHC compression. This chapter teaches the recommendation and its motivation, without claiming every deviation from SHOULD is forbidden. The jumbogram rule is a boundary note, not implemented by the ordinary-packet helper.