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 _______________________________________________ OPSEC mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsec
