4 ms·
Except you have to assume old code will be in deployment after the new code exists. The whole point of "reserved" fields is to tell old code not to freak out i
by hamburglar 11y ago
Except you have to assume old code will be in deployment after the new code exists. The whole point of "reserved" fields is to tell old code not to freak out if it sees new code using that field but doesn't understand it.
- kazinator 11y agoYes, of course, so when you're writing the strictly validating code, it has to be written with the assumption that although field must be zero now, that change in the future. And when it changes, the same code image will still be deployed in many places. Therefore, the validation cannot be hard coded; it has to be configurable so that the behavior can change to reflect the changed status of the field. This configurability has to be properly verified: does the equipment really stop validating and sending RST's in the "off" configuration for that field. RFC3360 says that sending RST is bad, and everyone please change that. It is written based on the fear that the rejecting behavior is hard-coded in some binary machine language images, so that if fixes aren't deployed now to get rid of the behavior, then when it becomes necessary to start using the field, it will be impossible, due to the need to roll out a massive upgrade to all sorts of networking equipment all over the world. The topic should be: "RST-generating checks that cannot be disabled without upgrading the software image on the networking equipment are harmful".