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

["C. M. Heard" <[e-mail]>]

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.

//cmh