Re: I-D Action:draft-ietf-6man-exthdr-01.txt

["Joel M. Halpern" <[e-mail]>]

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,