Hi Silvia and list, Weekend:-) Anyway: Silvia Hagen <silvia.hagen@sunny.ch> writes:
I keep stumbling about that "recommendational wording" in RFC 2460 everytime I teach it.
So do I. The problem underneath however is anything but trivial.
Couldn't we update RFC2460 and make this list a strict order?
As I understand it the way extension headers work was effectively a response to the severe limitations of header options in IPv4 (like 60 octets max, not even enough to do a proper record route option). The reason for the rather relaxed wording here is in all likelyhood that people at that time didn't want to impose any rules cast in stone which would later on turn out to be another similar limitation; for example, if a subsequently defined extension header was specified, it would be rather difficult to retrofit. However, with the experience we have with extension headers so far I guess you're right, it is likely time to investigate the possibility to make the ordering and such mandatory. That will allow for much better hardware implementations, if nothing else.
I would want my firewall to notify me if the EHs in a packet do not follow the list. And limiting the number of possible EHs per packet might be a good idea.
Right, but there are a number of differences between a firewall and a high end router, so this should really be investigated from a wide range of perspectives, from microcontroller based embedded devices to high end routers, and from consumer-managed home environments to high security environments. This is quite likely a pretty big job. Cheers, Benedikt -- Benedikt Stockebrand, Stepladder IT Training+Consulting Dipl.-Inform. http://www.stepladder-it.com/ Business Grade IPv6 --- Consulting, Training, Projects BIVBlog---Benedikt's IT Video Blog: http://www.stepladder-it.com/bivblog/