Pekka Savola wrote:True .. but firewalls of today don't even have a _chance_ of skipping over the extension header, even if they, or their administrators would want that (well, if the extension header is in TLV format, maybe then, because some firewalls assume the next ext headers are in TLV). Destination options at least allow that possibility.
If any future extension headers follow the canonical format:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Header | Hdr Ext Len | .... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
then one can build firewalls that are liberal in what they accept.
Sorry, I was just trying to figure out a term which says, "requires the host's shim layer and possibly some weirder middleboxes (like stateful firewalls, when they want to figure whether to pass this error in or not) have knowledge of applications' semantics [and if there are new such applications, requiring that this application knowledge to be updated], to be able to mangle the addresses inside the payload correctly."
It isn't "applications" - it is what I'd call "IP signaling protocols" or something like it; protocols which are not end-to-end but involve the routers along the path. ICMP errors from the routers, or RSVP signaling is what we currently have as examples. NSIS falls here as well.
-- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings