Re: [tcpm] RFC793bis draft 14 Reserved Bits

[Wesley Eddy <[e-mail]>]

On 12/3/2019 12:18 PM, Mike Kosek wrote:
>
> I would second the proposal to be more explicit. If we would add a 
> MUST of unaltered traversal in this specific case, I am wondering if 
> this should be addressed in other fields as well. Obviously there are 
> limitations for certain option types, or src/dst port, but Flags and 
> Window Size seem like perfect fits. Flags would also be the subsequent 
> step of Rodney's and Joe's proposal, as bits would not be covered any 
> longer if they are assigned.


In the case of reserved bits, I believe the reason we're trying to be so 
clear is that we want any new feature that might use them to work.  At 
least, in the past when this came up, that was why the current 793bis 
text on the reserved bits differs a little from the original 793 text 
(which is just "Reserved for future use. Must be zero.").

I think it would be a mistake and fruitless to try to say for the other 
individual fields which ones MUST be unaltered by the network.  
Generally, this is the expectation for the entire segment, even though 
that expectation doesn't typically hold anymore (due to NAT, etc).  I 
wouldn't say much more than that, because it's inviting misunderstanding 
that it's okay to twiddle with any bits and violate laying whenever the 
doc doesn't explicitly indicate not to.