-----BEGIN PGP SIGNED MESSAGE-----
>>>>> "Christian" == Christian Huitema <huitema@xxxxxxxxxxxxxxxxxxxxx> writes:
Christian> This restriction affects the way we design protocol
Christian> extensions. I see that as an argument for "in-band"
Christian> signaling, e.g. parameters in TCP packets or in IP
Christian> headers of TCP packets, by opposition to "out of band",
Christian> e.g. ICMP messages.
But, that doesn't work either.
The boxes that are responsible for 90% of the ICMP lossage were also
intolerant of the ECN options in TCP, and pretty much all TCP options in
general.
The boxes are broken.
The faster we make this clear, the better.
The biggest mistake we made with ICMP (and ICMPv6) was in assigning
an IP-level protocol number to it. We should have done it with IP
options instead. That would make it clear that the information carried
by ICMP is really part of layer 3, rather than being some new layer-4.
I don't have a fix for this, alas. I think the ICMP design was very
elegant. The problem has been a decade of firewall deployment done by people
who didn't understand the protocols. This can't be easily reversed.
- --
] "Elmo went to the wrong fundraiser" - The Simpson | firewalls [
] Michael Richardson, Xelerance Corporation, Ottawa, ON |net architect[
] mcr@xxxxxxxxxxxxx http://www.sandelman.ottawa.on.ca/mcr/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
Comment: Finger me for keys
iQCVAwUBQNCtgIqHRg3pndX9AQGhHAQAvWhae5RcpaNrX/1+ciuDKMX5bSordhMA
LXMADCkjMTH63e+91qMiG+kSqyDdPs7qHxppjPHXLZ2YgFwAU0CvjKhaV95Q3PJI
BMq43dPb4Veh3TaNKvLKkJmN1oli2uPV+i0fArq4plXXM7H2mBPeg+bQw9ckf/et
w8HQ/Vct9AE=
=FjVk
-----END PGP SIGNATURE-----
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf