Re: [v6ops] [OPSEC] Call for WG adoption - Recommendations on Filtering of IPv6 Packets Containing IPv6 Extension Headers

[Brian E Carpenter <[e-mail]>]

On 14/10/2014 03:38, C. M. Heard wrote:
> On Mon, 13 Oct 2014, Mikael Abrahamsson wrote:
>> On Mon, 13 Oct 2014, Ole Troan wrote:
>>>>> shouldn't this be a draft authored by operators? giving operational
>>>>> recommendations coming out of... well, actual operations?
>>>> Well, another way of looking at this is that operators just want things to
>>>> work as well as they can, so they need guidance from vendors and protocol
>>>> designers.
>>>>
>>>> Isn't this a BCOP style document? I believe at least one of the authors is
>>>> active in one or more BCOP group.
>>> the protocol designer's recommendation does appear pretty clear, RFC2460:
>>>
>>>   "With one exception, extension headers are not examined or processed
>>>   by any node along a packet's delivery path, until the packet reaches
>>>   the node (or each of the set of nodes, in the case of multicast)
>>>   identified in the Destination Address field of the IPv6 header."
> 
> RFC 7045, a standards-track document, explicitly changes that.  The 
> subject draft does not make any recommendations that contradict 
> RC 7045.  It supplements RFC 7045 where the latter does not fully 
> nail down the behaviour.
> 
> There is also draft-gont-6man-ipv6-opt-transmit, which (if 
> approved) will do the same for options that RFC 7045 does for 
> extension headers.  Same commens wrt that.
> 
>> You mean you don't want non-operators in the IETF to make recommendations?
>>
>> The way I see it is that vendors are making equipment based on customer
>> requirements. Since a lot of vendor equipment obviously inspect packets,
>> including those with extension headers along the way (probably to do ACLs),
>> then this equipment is already violating the functioning of the protocol
>> (which of course is nothing new).
>>
>> My opinion is that it's better to look at common implementation and document
>> and give recommendations where this differs from the blueprints.
>>
>> What I don't like is that if we follow along this path we're basically saying
>> "extension headers don't work on the Internet" which has the implication that
>> fewer will use them, meaning the vendors that don't follow the protocol
>> designer intention has little downside, and thus perpetuating the problem.
>>
>> I don't know how to make it right though. I would like to see extension
>> headers working well, but I also understand that people want to be able to do
>> filtering.
> 
> RFC 7045 revises IPv6 to acknowledge the reality of packet 
> inspection by forwarding devices, but lit levies requirements that, 
> if followed, should make the behaviour far less destructive.  The 
> sibject draft complements it with operational advice that is much in 
> the same spirit.

Exactly. I believe this draft, and the options draft, are *exactly* what
the IETF should do (and why we have an E in our name instead of an S;
we are not the Internet Standards Task Force). If our standards are
unrealistic, we should be the ones to do something about it...

   Brian