Hi
all,
This document aims to describe operational problems with HBH headers, and is a v6ops working group document. However, as it stands, it straddles several different subject matter areas: one of these areas is subject matter which relates to general IPv6 Extension Headers (EHs), i.e. not specific to HBH headers; one is design principles to address HBH processing, and one is practical limits in relation to IPv6 EH/HBH processing. These topics are more clearly and more comprehensively described in draft-ietf-6man-hbh-processing, draft-ietf-6man-eh-limits and rfc9098 ("Operational Implications of IPv6 Packets with Extension Headers"). To be clear, issues relating to HBH design principles and practical limits are 6man territory and aren't properly within scope for v6ops. I.e. this material should not be in a v6ops document. The draft-ietf-v6ops-hbh draft needs to stick to the aims in its title - and the aims of the v6ops working group - by describing operational issues relating specifically to HBH headers. The content which is not relevant to this should be removed, i.e. content which is previously published in other documents, or related to generic EH processing, or not applicable to the stated aims. Separate to this, I've previously raised the following technical issues with the authors on several occasions, but they were not addressed: - Section 1 is mostly a restatement of chunks of rfc9098 which applies to generic ipv6 EHs. On this specific issue, HBH headers are a subset of generic IPv6 headers and all problems described in 9098 are applicable to HBH. The stated purpose of the document is facilitate HBH options to be used in production, but no practical solutions are proposed in sections 8/9. There is no clarity which problems are specific to HBH and which are generic EH problems. - There are two parts to section 4 (Modern Router Architecture); the first is a discussion of router control planes/ forwarding plane interaction which doesn't really belong in a document about HBH headers in the first instance, but should arguably be dealt with in a separate informational document - not necessarily an RFC, but some reference document which would better describe how contemporary routers tend to operate. The second bit changes to a general discussion about HBH, all of which is repetition from other rfcs, mostly 9098. - Section 5 is a restatement of some material from rfc8200. This is unnecessary duplication. - Sections 6 and 7 are largely restatements of chunks of rfc9098 (duplication of material). - Section 8 (Design Principles) is a loose list of aspirations for HBH processing that is more clearly and more comprehensively described in draft-ietf-6man-hbh-processing. Some of the suggestions are principle-based; others practical based; but there is no guidance on how any of them could be achieved in practice. This section would be more appropriate for a design recommendation document (e.g. like draft-ietf-6man-hbh-processing or draft-ietf-6man-eh-limits), rather than an operational description document as it claims to be. - Section 9 (Migration Strategies) - as Job noted below - is too poorly specified to be usable in practice. Like the previous section, it states an aspiration but no concrete proposals about a new HBH header scheme, but doesn't indicate anywhere what this means or what the assumed old HBH scheme is. + Same comment about this content belonging in a design document rather than an ops document. These technical issues are very much secondary though. The important consideration is that if this is an operational document describing operational issues specific to HBH headers, it needs to be that, and not something else. I suggest that this document is pruned back, or better still rewritten, to become a tightly circumscribed operational doc which describes deltas between rfc9098 and issues which are specific to HBH headers. Assuming there's enough content in there, this could potentially become a work output of v6ops at some point in the future, and if so, then a useful basis for justifying the treatment of HBH headers proposed by draft-ietf-6man-hbh-processing, with further suggestions described in draft-ietf-6man-eh-limits. As the document currently stands, I don't think it adds enough value of the right kind to justify publication. Nick Job Snijders wrote on 19/08/2024 23:35: Dear all, This draft purports to end an "endless cycle": I quote "Break the endless cycle that resulted in HBH being a DOS vector." RFC 9098 explained why potential DOS vectors exist. To me, this draft draft-ietf-v6ops-hbh doesn't resolve the issues mentioned in RFC 9098. Section 4 "Modern Router Architecture" seems too simplistic. I suspect many router implementers wouldn't recognize their own work in this phrasing. Section 9 is under-specified to the point I considered it problematic. Kind regards, Job On Mon, Aug 19, 2024 at 02:47:53PM -0700, The IESG wrote:The IESG has received a request from the IPv6 Operations WG (v6ops) to consider the following document: - 'Operational Issues with Processing of the Hop-by-Hop Options Header' <draft-ietf-v6ops-hbh-10.txt> as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-call@xxxxxxxx mailing lists by 2024-09-02. Exceptionally, comments may be sent to iesg@xxxxxxxx instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document describes the processing of the Hop-by-Hop Options Header (HBH) in current routers in the aspects of standards specification, common implementations, and default operations. This document outlines reasons why the Hop-by-Hop Options Header is rarely utilized in current networks. In addition, this document describes how HBH Options Header could be used as a powerful mechanism allowing deployment and operations of new services requiring a more optimized way to leverage network resources of an infrastructure. The purpose of this draft is to document reasons why HBH Options Header is rarely used within networks. It motivates the benefits and requirements needed to enable wider use of HBH Options. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-v6ops-hbh/ No IPR declarations have been submitted directly on this I-D. _______________________________________________ IETF-Announce mailing list -- ietf-announce@xxxxxxxx To unsubscribe send an email to ietf-announce-leave@xxxxxxxx_______________________________________________ v6ops mailing list -- v6ops@xxxxxxxx To unsubscribe send an email to v6ops-leave@xxxxxxxx |
-- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
