On 24 May 2013, at 13:40, John Leslie <j...@jlc.net> wrote:

> Ray Hunter <v6...@globis.net> wrote:
>> 
>> I would also like to see some text on whether it is possible/desirable
>> for a middleware box to strip unknown headers, or even some known
>> headers, rather than making a binary decision to drop or transmit the
>> entire packet. If (new) headers are truly optional or experimental, the
>> residual stripped packet may still have value e.g. stripping hop by hop
>> extension headers on entry to/ egress from a corporate network or
>> transit AS. That way the (new) extension headers could be usefully
>> deployed in an AS that supports them, but the end to end traffic would
>> not be blocked further along the path by firewalls in an AS that does not.
> 
>   I had a similar thought -- even going so far as to posit a way to
> notate that a header had been stripped...

For that you need a new header... ;)

>   I think the answer is we don't want to do that in this document;
> nonetheless some folks are likely to try it. I think a mention of the
> issue, and a reference to RFC(s) stating the current rules, would help.
> 
>   (The prime purpose of this document is creating an IANA registry;
> that purpose should not be clouded by discussion of what firewalls
> "should" do.)

Yes, the doc should focus on its primary reason for existence. 

A couple of additional comments.

One is that from time to time there may be security issues raised with certain 
headers, e.g. RH0. These may obviously be raised over time. Is there a 
mechanism to catch these in the IANA registry somehow?

Another is whether there is any use of the "null" header type 59?  Or has that 
been deprecated?  If not, should it be so, given Brian doesn't list it.  Or is 
this viewed in the same category as TCP, etc as header types?

Tim

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

Reply via email to