On Fri, Mar 08, 2002 at 03:18:36PM +0100, Henrik Nordstrom wrote: > But still, what is the validity in enforcing that fields "reserved > for future use" is zero in a firewall? > > Doing so will with no doubt create serious incompabilities the day > these bits starts to be used for anything, just as the ECN change > has. There is still a huge amount of sites that do not accept ECN > flagged traffic even if the ECN extension is proposed standard track > since long back. This due mainly to various kinds of firewalls beeing > too picky about "reserved for future use" bits, which in the ECN case > even was defined once in a time and then later became reserved. > > The compliance definition about the ECN bits mainly worries about the > bits having a different original meaning, not that the bits has been > reserved for future use (naturally). > > Having a "unclean" standard match that matches things like this (use > of reserved fields) is very questionable, and may cause serious > implications later on if people actually uses things like this in > filtering.
Exactly. This is the main reason why I think we should discourage the use of the 'unclean' match. Marking it as experimental lets people think twice - and if it later breaks we can point at them and tell them: "You've used experimental code, you were supposed to know what it will do in the future" > Summary: For once I strongly agree with Harald. A match like > "unclean" should not ever be anything but experimental. hey, let's party ;) we agree on something. > Regards > Henrik Nordström > MARA Systems AB -- Live long and prosper - Harald Welte / [EMAIL PROTECTED] http://www.gnumonks.org/ ============================================================================ GCS/E/IT d- s-: a-- C+++ UL++++$ P+++ L++++$ E--- W- N++ o? K- w--- O- M+ V-- PS++ PE-- Y++ PGP++ t+ 5-- !X !R tv-- b+++ !DI !D G+ e* h--- r++ y+(*)
