Then what about if we forget firewalls for the moment?
A lot of routers look for the TCP/UDP Port numbers for LAG/ECMP computation.
Many of them can cope with having a destination options extension, and
therefore that is clearly the better way to handle such information.
And anything we do should make that strong preference clear.
Nothing we can do can change the way routers with silicon already
deployed handle unknown extension headers.
Given that, one option is to just say that new extension headers should
not be used.
If we think that there will be some new extension headers, that we want
to support, designed for the general Internet, then it would seem to
make sense to try to get new behavior defined, supported, and then used,
that will allow for such extensions. In that case, requiring and
documenting the requirement for new extension headers to use TLV
encoding would seem to have applicability and utility.
Yours,
Joel
On 1/4/2011 12:17 PM, Fernando Gont wrote:
Hi, Thomas,
On 04/01/2011 11:29 a.m., Thomas Narten wrote:
From the POV of a firewall, unless it really wants a packet to
pass-through, it will block it.
I think this is the crux of the problem. firewalls, by default,
discard stuff. They don't like the idea of allowing unknown or
"uncommon" things through. Defining new options and expecting
firewalls to give them a blank check to go through I suspect is
wishful thinking.
And look at this from the perspective of someone who wants to deploy a
new option. If 80% of the firewalls allow the new option through, will
this be good enough for deployment? Doubtful. What about 98%
cooperation from firewalls? Again, quite possibly not.
I fully agree with you.
Unless this document is widely implemented in practice, it's far from
clear it is useful.
Whether it's widely deployed is, IMHO, irrelevant. Two cases:
* The I-D is not deployed (firewalls can't go past new extension
headers). -- but the very presence of the unknown headers is what causes
the fw to block the packets.
* The I-D is deployed. The presence of an "uncommon" extension header
causes the fw to block the packet (even when it could, *if* it wanted go
past the "uncommon" extension header).
As you correctly stated it, the crux of the problem is that this
document assumes that firewalls are willing to allow stuff that they
don't understand. -- but they aren't. They are meant to only allow stuff
that is needed.
Thanks,
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
