3 ms·

> Bullshit. Non-zero in a reserved field that has no meaning now, and should be loudly diagnosed as an error until such a time that it has a meaning. This make

> Bullshit. Non-zero in a reserved field that has no meaning now, and should be loudly diagnosed as an error until such a time that it has a meaning. This makes no sense. You must treat a reserved field as meaningless and having no consequence, otherwise eventually, when it does have meaning and your old code is looking at packets, you're going to start "loudly diagnosing" all over the place.

kazinator 11y ago
You have to replace that old code, obviously. Or, much better yet, configure it not to do the diagnosing any more. That's a separate concern, one of "what happens if this field starts being used, but old code is still in wide deployment". It doesn't negate the basic principle.
- 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 ago
    Yes, 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".

kazinator 11y ago

You have to replace that old code, obviously. Or, much better yet, configure it not to do the diagnosing any more. That's a separate concern, one of "what happens if this field starts being used, but old code is still in wide deployment". It doesn't negate the basic principle.

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 ago
  Yes, 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".