[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Comments on multi6dt documents
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.
But I still think this is moot because firewalls by nature will be
conservative in what they accept.
Right out, I can't think of anything else than ICMP and multicast (which
you already mentioned), but that doesn't of course mean those kind of
protocols might not exist. Therefore I think it would make sense to put
this sufficiently clearly in the document that people need to keep in
mind that there may be some protocols which might call for special
ok, I'll add some words.
Why do you wish to confuse things by calling it an ALG? It is a local
matter for the implementation how it demuxes ICMP errors. ALGs and
NATs make people think of middleboxes which perform transformations
which can not be reversed.
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.