I've written a small iptables target for the iptables 'mangle' chain, which
allows users to remove the ECN bits of the IPv4 header ::on a per-rule basis.
It forces the ECN bits of the IPv4 header to codepoint 00 == not-ECT as well
as the two ECN bits in the TCP header to 00;
This allows users to selectively work around ECN blackholes.
Currently you basically have the following options:
a) Turn ECN on and complain to the respective admins for all blackholes
you find. This is the optimum case. Unfortunately you don't always succeed
in convincing them that it's their fault. I'm personally going for this
'option' for quite some time - with varying results. This is not an
option for most people.
b) Turn off ECN and don't care about the whole discussion
With ECN turned off on lots of theoretically ECN-capable hosts, the
deployment of ECN will be much slower than it could be. This is what
most people (and vendors) are currently doing. Very unfortunate.
My iptables target would add a new option
c) Generally enable ECN, but have a small blacklist of sites / networks
which are known ECN blackholes. IMHO, this approach combines the
advantages of a) and b). People can activate ECN, and add a per-host
no-ecn rule in case they detect blackholes and can't LART the
responsible administrators who cause the blackhole.
The question is: Would this iptables extension be considered a candidate
for inclusion in the stock kernel? It's evil, I know. But on the other
hand very useful :)
If yes, I'll submit it to DaveM for kernel inclusion.
Live long and prosper
- Harald Welte / laforge@xxxxxxxxxxxx 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+(*)