Graham Murray wrote:
> "David S. Miller" <davem@redhat.com> writes:
>
> > The authors of rfc793 probably, in all honesty, really meant
> > "must be set to zero by current implementations".
>
> I agree, to me it seems obvious that the reason is so that these bits
> could be used at some time in the future for some, then unknown,
> purpose. Now that RFC 2481 has defined the bits, only implementations
> which grok and support ECN should be setting these bits, older
> implementations will (following RFC793) set them to zero and thus old
> and new implementations should correctly interwork.
The RFC 793 authors really should have stated that non-zero bits on
incoming packets are reserved for future protocol extensions, and should
be silently accepted and ignored.
RFC 793 predates modern firewalls AFAIK. There just wasn't a need for
protection from things like DDOS's, teardrop etc.
Now, for how to deal with firewalls that block ECN. Perhaps it's a
_good_ thing that they send RSTs. Presumably the RSTs don't have ECN
bits set. So our TCP stack can observe this and say "ah, that route
doesn't do ECN; let's retry without ECN and see if we get a better
response".
-- Jamie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Sep 15 2000 - 21:00:11 EST