On 01/12/2024 18:39, Tom Herbert wrote:
Gorry, This review is way too long for me to process easily. Can you provide the diffs between versions? Also can you remove things that are settled. For instance, there is plenty of precedent that RFC2119 language can be used in an Informational RFC, especially RFC6434. Can you withdraw those comments? I think you are reading this draft too much from a theoretical perspective and not enough from a pragmatic perspective. This draft is pragmatic to make Extension Headers deployable in the world. In particular, several times in the review you state that this draft could ossify IPv6, significantly limit the ability to change the future, ossify the IPv6 header structure, significant impacts of the ability for IPv6 to evolve, and so on. Those are very scary and alarming words! But they're use is also misguided. The problems you're concerned about _already_ exist in the real world. The idea that implementers just read the spec and implement that exactly is a fantasy, we need to make a practical implementation based on the spec which sometimes won't conform and that's where ossification begins. So the purpose of this draft isn't to exacerbate the problem, but to address it by acknowledging that nodes don't have an infinite number of resources to process every conceivable combination. For example, RFC8200 states that a host must process any number of extension headers in a packet. That requirement is simply *not* feasible. Someone could stuff over 150 Destination Options headers into a single packet filled with nothing but padding. That is a _lot_ of processing on a host and with no effect-- the only purpose of this is DoS attack. So we need to limit the number of EH headers (avoiding DoS is a real problem, the off chance that someone may come up with a valid use case of more than even one Destination Option header in a packet much less a hundred of them is not enough to warrant high limits). So whether or not this draft is published, host stacks are going to put limits on extension headers. IMO, providing consistent guidance on how to do that is far better than letting everyone decide what to do on their own. Tom
Thanks for looking at this.
The only addition in my update were notes, and some minor corrections, these are tagged as "Note:".
What you suggest is not the way that it works with directorate
reviews. I'll only re-review if I am requested, e.g. after a new
revision is published.
Indeed, you are correct it can be OK to use normative language in an INFO publication. That's not the issue raised in this review. My comments relate to new normative statments about parts of a spec. that were previously informative, or the paraphrasing of existing recommendations rather than citing these.
On Sun, Dec 1, 2024 at 1:57 AM Gorry Fairhurst <gorry@xxxxxxxxxxxxxx> wrote:Tom, Thanks for taking the care to read and respond to the review. I normally review starting from the I-D, not the working groupo discussion, so thanks for the feedback. With the issue of making a long review longer, I've revised my review based on some of your comments, by adding notes - in most cases these note that your text seems a paraphrase/clarification of the IPv6 node requirments, and I tried to identify what was changed there, and adopting thsi approach would I think improve the draft. I've also tried to explain where I saw potential "node" rather than "host" changes. I also was promted to look back at the WGLC and say some topics, which did not yet seem resolved and adds notes regarding this. Best wishes, Gorry On 27/11/2024 23:57, Tom Herbert wrote:On Wed, Nov 27, 2024 at 1:47 AM Gorry Fairhurst via Datatracker <noreply@xxxxxxxx> wrote:Reviewer: Gorry Fairhurst Review result: Not ReadyHi Gorry, Thanks for the review, Comments inline.This document has been reviewed as part of the transport area review team's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors and WG to allow them to address any issues raised and also to the IETF discussion list for information. When done at the time of IETF Last Call, the authors should consider this review as part of the last-call comments they receive. Please always CC tsv-art@xxxxxxxx if you reply to or forward this review. Review for "Limits on Sending and Processing IPv6 Extension Headers" The document seeks to provide informational guidance on how to best configure limits to IPv6 Extension Header processing. It seems to provide two contributions: - It seeks to ossify the IPv6 header structure, by suggesting to deploy checks in routers and other nodes that drop packets when they do not conform. - It seeks to recommend values for the size and number of extensions/options that may be expected to be included in an IPv6 packet. The two contributions together seek to ease deployment of some types of extension, by specifying minimum expectations. On the one hand, if deployed this would ease section of appropriate sized header chains by endpoints that would increase the chance of successful use across an end-to-end path. One advantage of this approach is that it could encourage greater deployment of in-network and stack support for extension headers. On the other hand, this would also result in discard of packets that include extension headers that do not conform (in size or structure). This will prevent other (new) types of extension. If published, it will likely have the impact of ossifying IPv6 around these constraints, this will simplify the design, but thought is needed around how to evolve to add different features in future.I disagree with that, especially the idea that this draft is ossifying IPv6. The whole purpose of this draft is to undo the ossification that has prevented deployment of IPv6 extension headers-- particularly, the tendency for many routers to just drop packets with Extension Headers or defer them to slow path processing is addressed by providing practical guidance.The document discusses extension header use at end hosts, by routers, by middle boxes, firewalls and devices performing operations such as ECMP. Although an INT area specification, this has impact on whether an endpoint is able to include destination and HBH options in packets that it sends, and therefore it impacts has implications on the transport, which includes methods such as racing, the use of tunnels/encapsulation by the end-to-end transport, and methods such as OAM. It also impacts the design of middle boxes.Yes, also note that this works the other direction. QUIC, RFC9000, sets some limits on the length of Extension Headers in packets.In summary, I think the draft is not ready for publication. This document has several major issues. In all text below, the word "OLD" refers to the reviewed revision of the I-D. General Review Comments: 1. Use of RFC 2119 Language This draft contains RFC 2119 requirements language, which maybe is not needed in an INFO document. I’d suggest using only lower case terms, which would also remove the burden of proof that these are the correct terms in each case.As I pointed out in other responses, this draft is following the same trajectory as RFC8504 a BCP which obsoleted RFC6434 which was Informational and did use RFC2119 requirements language. If the consensus or ADs want to remove the language then of course we can, but personally I think that would water down the draft to the point it might be meaningless.2. The I-D refers to itself as a specification in multiple places. For example: OLD: This specification includes limits on extension headers NEW: This document includes limits on extension headers --- - This reviewer suggests to use the word “document” throughout, because this is to be published as Informational.Okay.3. The appendix needs clearer scope to provide only the required background information, not reiterate requirements. In the Annexe, OLD: This scheme thus establishes a requirement that Internet devices must be capable of correctly processing packets with up to sixty-four bytes of extension headers, and subsequently it establishes a requirement that a host shouldn't send packets with more than sixty- four bytes of extension headers unless it known that all the nodes in the path can process packets with larger extension headers and a larger IPv6 header chain. Note that this establishes a global minimum baseline requirement across the Internet; within a limited domain higher limits could freely be applied. --- - This language seems excessively strong for informational documentation. - I would hope it establishes an expectation that Internet devices are able to process packets. - It does not set requirements, but it could give very useful guidance. - If published this guidance might be expected to become the norm, which will ossify (significantly limit) the ability to change in future.Yes, but the draft is very clear that these are _minimum_ requirements. Currently, the standard says that the extension header length could be up to MTU, but de facto minimum support which is widely deployed is zero bytes. That minimum is the direct result of ossification which precludes the use of Extension Headers on the Internet. So, IMO, requiring a minimum level of support that is greater than zero but less than infinity is not exacerbating ossification, but is in fact addressing it.========= Major issues: 1. This is an INT Area spec twith text that appears to speak about middleboxes, firewalls etc, but doesn’t really say so or discuss how they ought to operate. In particular the text motivates that routers ought to be able to interpret the transport headers:The draft describes the behaviors that routers, hosts, and intermediate destinations follow wrt applying limits and what happens when limits are exceeded. The specific operation of that is outside the auspices of this draft and is covered elsewhere.“If a router needs to parse the upper layer protocol, for instance to deduce the transport layer port numbers, it MUST be able to correctly forward packets that contain an IPv6 header chain of 104 or fewer bytes, or equivalently, a router MUST be able to process a packet with an aggregate length of extension headers less than or equal to 64 bytes. " In the Appendix, OLD: A de facto requirement of many routers is that they need to process transport layer headers in packets. --- - I think this needs more clarification, and specifically ought to note the implications of performing deep packet inspection and mitigations there are to avoid this (see note on at least discussing the flow table as one remedy for ECMP). - The growing use of VPN and other encryption makes this particularly short-sighted. Although perhaps noting the intent of the flow label might help in such an argument to mitigate the ossification around using transport information in the network.I'm not sure what you think is short-sighted, is it the fact that some routers have ad hoc requirements to access the transport layer headers, or that we're trying to provide some reasonable guidance when they do that? I would agree with the former, but not the latter :-)2. Please check the relationship to the recently published RFC 9673 OLD: Routers are susceptible to the attack using Hop-by-Hop options, hosts are susceptible using Hop-by-Hop options or Destination options, and intermediate nodes are susceptible using Hop-by-Hop options or Destination options before the Routing Header. --- - - This seems to be no longer true after publication of RFC 9673, “IPv6 Hop-by-Hop Options Processing Procedures”, making HBH options skippable. RFC 9673 also sets configuration control that permits: “A configuration could control whether normal processing skips any or all of the Hop-by-Hop options carried in the Hop-by-Hop Options header.”RFC9673 does not discuss Destination options, we cannot skip them in host processing. Also, while RFC9673 does allow nodes to skip some number of nodes, it provides no use guidance on how many options can be skipped without adversely affecting functionality and extensibility (that is what this draft does), Also about RFC9673, the draft states: "A Source MAY, based on local configuration, allow only one Hop-by-Hop option to be included in a packet, or it could allow more than one Hop-by-Hop option but limit their size to increase the likelihood of successful transfer across a network path." This text implies a default limit of one option, which could be inferred to be ossifying and limiting the evolution of IPv6 as much as this draft does. Restricting senders to only one option seems way too limiting (note, that I argued against this text in draft discussions and other requirements that could be inferred as setting limits). Also, "limiting their size to increase the likelihood of successful transfer across a network path" is useless guidance to me as an implementer-- do I need to limit it to 8 bytes, 64 bytes, 1024 bytes?.. we don't know. This is precisely why the header limits in this draft are so important, we can give intelligent guidance to a sender as to what they should reasonably expect to work, and guidance to receivers so that they can meet at least these minimum expectations (greater than zero).3. The following comments relate to changes that update the text of RFC8200, in terms of the structure of the header chain. This is a full standard, and there is no updates field to indicate there are changes to the specification of RF8200 (which might otherwise be a DOWN REF for an Informational I-D to makes new stronger rules for processing than currently defined in a standard). When I reviewed the I-D, The document does not explain how these proposed changes were analysed or motivated. See below: 3.1 Would update RFC 8200 processing order of extension headers: OLD: A host or intermediate MAY enforce the recommended extension eader ordering and number of occurrences of extension headers described in Section 4.1 of [RFC8200]. Per the ordering recommendations, each extension header can occur at most once in a packet with the exception of Destination Options header which can occur twice.The MAY should be a "may". This draft does not update RFC8200,---. and OLD: If a host or intermediate node enforces extension header ordering and a packet is received with extension headers out of order or the number of occurrences of an extension header is greater than one, or two for the Destination Options header, then the receiving node SHOULD discard the packet and MAY send an ICMP Parameter Problem message with code 8 (Too Many Extension Headers) [RFC8883] to the packet's source address.Note the prefaced condition that sets the applicability of the requirements.---. and OLD: Note that a host may enforce extension header ordering for all extension headers in a packet, but an intermediate node may only enforce ordering for extension headers up to and including the Routing Header. --- - RFC 8200, section 4.1, makes non-normative statements about the ordering of extension headers: RFC 8200: When more than one extension header is used in the same packet, it is recommended that those headers appear in the following order: ... --- - RFC 8200 the continues to say: “If and when other extension headers are defined, their ordering constraints relative to the above listed headers must be specified” and RFC8200 states: IPv6 nodes must accept and attempt to process extension headers in any order and occurring any number of times in the same packet, except for the Hop-by-Hop Options header, which is restricted to appear immediately after an IPv6 header only. Nonetheless, it is strongly advised that sources of IPv6 packets adhere to the above recommended order until and unless subsequent specifications revise that recommendation. --- - Therefore this I-D, if published, will change these recommendations by suggesting a different set of rules for processing, or at least would change the non-normative expectation of this full standard. - From a transport perspective, enforcing extension header ordering for extension headers included in a packet within an intermediate seems like it is a new obstacle for incremental deployment.But, this draft _is_not_ requiring ordering or changing RFC8200. It is saying that _if_ a node chooses to apply restrictions or limits to protocol processing that are not mentioned or sanctioned by the Standard then this is the recommended way to do that to maintain interoperability and the spirit of Standard as much as possible.3.2 This would update RFC 8200 with new stronger rules for the number of times an extension header can appear, restricting what is currently allowed. RFC 8200: Each extension header should occur at most once, except for the Destination Options header, which should occur at most twice (once before a Routing header and once before the upper-layer header). --- - - Is there evidence (I did not see a reference) that says whether this will cause more paths to drop packets, or whether this is expected to encourage more paths. Is there any measurement data? - From a transport perspective: Enforcing extension header ordering for extension headers included in a packet within an intermediate seems like it is a potential obstacle for incremental deployment. 3.3 This would change the method in RFC 9673, which motivates skipping unknown or un-configured HBH options. OLD : It is NOT RECOMMENDED that the router discards the packet because the limit is exceeded, however if it does then the router MAY send an ICMP Parameter Problem message --- and OLD: If a packet is received and the number of Destination or Hop-by-Hop options exceeds the limit, then the receiving node SHOULD discard the packet and MAY send an ICMP Parameter Problem message with code 9 (Too Many Options in Extension Header) [RFC8883] to the packet's source address. --- - It seems to change the expectation in RFC 9673 by specifying different rules when more HBH options within an EH than expected (i.e., it says “not recommended” rather than RECOMMENDED to skip). This change appears to create more opportunities for path failure (discard of packets by a path), was this change intended? 3.4 If published, this would update RFC 8200 with new stronger rules for generating ICMPv6 messages. - In various places there is text about optionally generating ICMPv6 messages, whereas RFC8200 seems to indicate nodes should generate ICMP messages when packets are discarded. This could be OK, but is there a reference to support this rule? OLD: It is NOT RECOMMENDED that the router discards the packet because the limit is exceeded, however if it does then the router MAY send an ICMP Parameter Problem message --- - There was a general principle that packet discard should result in ICMPv6 messages indicating the problem encountered, which seems to be what RFC8200 states. It is not the case that endpoints expect to see these messages, none-the-less this isn’t a PS and therefore this should likely point to the RFC that describes when ICMPv6 is used.RFC8333 is already defined. Like any other ICMP errors, endpoints can take action on them or not per their discretion.4. The following new rule partly seems to contradict another new rule in this I-D: OLD: If a limit is exceeded, routers SHOULD still forward the packet and SHOULD NOT drop packets because a limit is exceeded. --- The conflict is with, OLD: A router MAY disallow consecutive padding options, either PAD1 or PADN, to be present in the Hop-by-Hop Options header. If a packet is received with consecutive padding options that are disallowed by the router, then the router SHOULD stop processing the Hop-by- Hop Option header and ignore any Hop-by-Hop options beyond the limit. It is NOT RECOMMENDED that the router discards the packet because the limit is exceeded, however if it does then the router MAY send an ICMP Parameter Problem message with code 7 (Too Many Options in Extension Header) [RFC8883] to the packet's source address. --- - Could this rule be changed to “Routers ought to forward packet when the limit is exceeded” - In which case, ought they not also to skip the remaining options and process the packet, which might involve processing additional extension headers?I don't believe there is a conflict here. The first requirement sets a general requirement for router behavior. The second requirement provides details on the behavior including what to do in the exception case for the SHOULD of the first requirement.5. Why is the rule about only one PAD option needed? OLD: A source host SHOULD NOT set more than one consecutive pad option, either PAD1 or PADN, in a Destination Options header or Hop-by-Hop Options header. --- and later , OLD: host or intermediate node MAY disallow consecutive padding options, either PAD1 or PADN, to be present in a packet. If a packet is received with consecutive padding options that are disallowed by the receiving node, then the receiving node SHOULD discard the packet and MAY send an ICMP Parameter Problem message with code 9 (Too Many Options in Extension Header) [RFC8883] to the packet's source address. --- and OLD: In addition to a limit on the number of consecutive bytes of padding, this specification allows a receiver to disallow consecutive padding options. The rationale is that a single PAD1 or PADN option can be used to provide 1 to 257 bytes of padding which is sufficient for any practical use case. Correspondingly, this specification also recommends that a sender does not send a packet with consecutive padding options. --- - Why is it necessary that this restriction on PAD processing is needed? - It was previously allowed to send multiple PAD options (albeit with no upper limit on the total number of options). For testing, a sender could replace an option with a PAD, but that could result in more than one PAD option, which could with the new I-D cause the packet to be discarded. - Is there an important reason why the limit of 8 options cannot include more than one PAD option?The padding options as well as other options are from RFC8504. This draft clarifies behavior, and extends the requirements to be applicable to non end hosts.6. Does that mean a host becomes restricted in how it can use destination options end-to-end when it includes (for example SRV) extension header?No. If a host is setting some limits then it would account for SR header. SRv6 would only be used in a limited domain so it's up to the operator to ensure compatibility (note that this draft doesn't change anything, use of the extension header is predicated on it being able to transit the path. The limits in this draft are really intended to be used when sending to hosts over a network for which nothing is known about their capabilities (.e.g the sending on the Internet).OLD: A source host SHOULD NOT send a packet with an IPv6 header chain larger than 104 bytes unless it has explicit knowledge that all possible routers, intermediate nodes, and the destination host in the path are able to process a larger IPv6 header chain. If a packet contains an IPsec header then this limit only applies through the end of the IPsec header (the IPsec header obfuscates following headers so that they are unreadable by nodes in the path). This requirement is equivalently stated as a host SHOULD NOT send a packet with more than 64 bytes of aggregate extension headers. --- - Does this have implications at the transport layer on what destination and HBH options can be sent? The problem I fail to understand is how the processing on the path impacts the choices available at the endpoints, especially if the set of EH are not delivered to the final transport endpoint. - Restrictions arising from a need for visibility of the transport header seem a significant change to the IPv6 specification. For a packet that includes a routing header or other extension header used on a part of the path, it then appears to limit what options/size the host can use end-to-end across the transport connection. Similarly, the document does not discuss the addition of extension headers for purposes such as OAM, which I also assume that an endpoint needs to discover before it adds extensions - since network paths might then “police” the overall header chain?I think you're looking at this the wrong way. The goal isn't to "police" but to give the _existing_ "police" guidance to do a better job so we can break their ossification. The "police" are firewalls and routers that take upon themselves to not only "police" but to also define the rules without any openness. For instance, this draft addresses the problem that some routers that today drop all packets with any protocol other than TCP or UDP. If we give them better, practical guidance, maybe they can change these practices and hence move the needle on resolving ossification. Also, all of the limits in this draft are completely optional. We are not requiring anyone to set any limits (with the exception of the header chain limit in routers). Furthermore, the draft is also clear that any limits may be freely exceeded if the environment is well understood. So for protocols like IOAM, SRv6 that are only deployed in limited domains there is no conflict with limits.- How do these restrictions apply to the processing of packets that include an IPSEC header, tunnel extension, or something similar that relate to all or a part of the path being used? How does the sending endpoint discover this limit that appears on-path? It seems the only way to evolve and use new headers is for the transport to use a method that would deliberately hide the extension headers from the routers on the path (as in IPsec currently), which appears to prevent access on the path to the transport header (which was one of the motives of this proposal). Please calrify how this evolution will play out.IPsec and tunnel extensions are end-to-end. Routers only process HBH and nothing beyond. The only other consideration for routers is the header chain limit when a router needs to access the transport layer. Obviously, if IPsec is used the transport headers are unavailable, but that is not this draft's concern. All this draft is saying is that the mere presence of extension headers is not sufficient justification to drop a packet. Routers have to accept some non-zero length EHs when they are parsing over EH.7. I have concerns about the completeness of the analysis of the currently deployed support (see Appendix). This could be remedied by citing and comparing a range of sources. It is generally unwise to base decisions on presentations, and I would encourage a wider set of sources (single point measurements are prone to bias from using a specific vantage point from which to measure - which is the topic of [Cus23a]). Please use archived journal publications (where the scientific rigour/review helps support the claims and the methodology is clear).Will add references.8. The document is complex and can have significant impacts of the ability for IPv6 to evolve. This document includes both restrictions to the structure of extension headers (e.g. the ordering) and recommendations of the size of extension headers. I can see significant merit in reviewing whether both of these changes are necessary, and if they are both needed, then to place these in separate documents.The concern that this draft would ossify the IPv6 or limit its evolution seems to be a running theme in the comments, so I summarize several points in rebuttal. 1. Considering that we've had thirty years of experience with IPv6 and there is virtually no deployment of Extension Headers on the Internet, I'm not at all worried that _this_ is the draft that people will cite as inhibiting the evolution of IPv6 :-). In reality, the reason that EH hasn't yet succeeded isn't because it was too restricted, it's because the requirements are too open ended. Requiring a router to process every HBH option, or a host to process any number of EHs and all options in a packet are not realistic. We simply cannot build a usable Internet on the premise that nodes have unlimited resources to process an unlimited number of items. In lieu of IETF providing any useful guidance to address this, individual implementations have taken it upon themselves to define pragmatic limits. Unfortunately, that has resulted in implementations being all over the place and basically we're stuck with the Least Common Denominator which currently seems to be a limit of zero (hence, we can't use EH on the Internet). 2. This draft is about _all_ extension headers, not just HBH. Sometimes I get the feeling that people only see the problem of packet processing at routers (for instance, in the above comments RFC9673 is cited as addressing some issues, however that RFC is only concerned with HBH and says nothing about Destination Options or other EH). Once RFC8200 allowed routers to ignore HBH options that actually solves most of the router problem (except for the DPI and parsing buffer to access transport headers which is addressed by the router limits for EH length). While the problem may be solved for routers, for hosts it's a different story. Unlike a router, a host stack is required to process all EHs, all Destination Options, and IMO should have to process all HBH to address the security concerns cited above. While hosts might have more resources than a router to process headers, they also have a lot more requirements on what to process and hence have a greater exposure to DoS attacks involving EH. So limits on EH2 are paramount in a host stack, which leads to the third point... 3. Concerning the host side, most of the applicable limits are already implemented in Linux and have been deployed for a while (at least four years). So to a large extent, this draft isn't proposing host limits, it's documenting them! This includes padding limits and the number of HBH/DestOpts allowed. For instance, if a Linux server receives a packet with more than eight HBH options, it will drop the packet by default. I suppose a protocol purist might complain that we're violating RFC8200 and some time, probably in the distant future, someone might come up with a legitimate use case for nine options. But until that happens, such a complaint would fall on deaf ears. Protecting users and systems from an obvious DoS attack clearly trumps allowing unlimited extensibility that was not anywhere close to needing. Tom========= Comments related to the document structure/editorial: 1. Including Extension Headers I recall the appropriate language concerning extension headers is to describe this as “packets that include extension headers”, as per RFC 8200. 2. In the abstract, OLD: The need for such limits is pragmatic to facilitate interoperability amongst hosts and routers in the presence of extension headers, thereby increasing the feasibility of deployment of extension headers. --- - This sentence was difficult to read and distill. I’d have understood this quicker, if I understood the goal was to introduce limits that can improve the deployability of extension headers, or something similar. 3. OLD: The lack of limits and the requirements for supporting a virtually open-ended protocol have led to a significant lack of support and deployment of extension headers ([RFC7872], [Cus23b]). Suggested NEW: The lack of limits and the requirements for supporting a virtually open-ended protocol have led to a current lack of support and deployment of extension headers ([RFC7872], [Cus23b]). --- - I am always super-wary about making statements about significance and level of support in the RFC series. As an archived document it seems better not to judge a “significant lack of support” without qualifying that this is the current state at the time of writing. Too often, a claim is re-cited in other places and for other reasons so I would encourage this to be qualified by at the time of writing and to remove the word “significant”. 4. OLD: The net effect of this situation is that deployment and use of extension headers is underwhelming to the extent that they are sometimes considered unusable on the Internet, and hence IPv6 extension headers have not lived up to their potential as the extensibility mechanism of IPv6. --- - This appears overtly negative. As above, I’d strongly encourage the sentence to be re-phrased. Could it simply state the clear benefit that arises from deployable methods? 5. OLD: As an example, consider that there is no limit on how many Hop-by-Hop or Destination options may be in an extension header in a packet, nor any limits as to how many options a receiver must process. --- - This seems to be a statement about current deployment. Could the word “currently” be added? 6. OLD: Any node in the path that attempts to dutifully process all these options could be easily overwhelmed by the processing needed to parse these options, hence this is an effective DOS attack. Suggested NEW : A node on the path that attempts to process all options could become overwhelmed by the processing needed to parse these options, resulting in a vulnerability that could be exploited by a DOS attack. --- - “an effective…attack” seems an odd way to describe a vulnerability that could be currently exploited. I expect this could be rephrased, perhaps similar to what is suggested above? 7. Section 2 , OLD: limited is exceeded then the router skips NEW: limit is exceeded then the router skips --- - This seems to be a statement about current deployment. There is a possible typo in the current text? 8. OLD: The rationale is that the only extension header a router may process is Hop-by-Hop Options and the packet can be correctly forwarded if none or some of the Hop-by-Hop options are processed. --- - Partly true, but I note that intermediate nodes process Segment Routing Headers. Maybe the text could be updated? 9. In Appendix: A.2. Limits on length OLD: The 104 byte limit is derived from an assumed parsing buffer size of 128 bytes. --- - This seems to be a statement about current deployment. I’d suggest to say “At the the time of writing….” 10. In Appendix: A.2. Limits on length, OLD: The default IPv6 header chain limit is derived from the expected size of parsing buffers assuming that there is space to accommodate the first bytes of the transport layer header in the parsing buffer. --- - I’d suggest to say “At the the time of writing….” 11. In Appendix: A.2. Limits on length, OLD: N ote that limit on seven consecutive bytes of padding is "hardcoded" and enforced in the Linux networking stack. --- - - I’d suggest to say “At the the time of writing….” 12. OLD: Security issues with IPv6 extension headers are well known and have been documented in several places including [RFC6398], [RFC6192], [RFC7045], [RFC4942], and [RFC9098]. ---. - Please also add a reference to the security discussion in RFC 9673. 13. In the para starting “A host or intermediate node MAY set a limit on the maximum length” two terms are used: “ aggregate length of extension headers in a packet” and " IPv6 header chain “ - - Please could this be rewritten to use just one term? 14. In Annexe, OLD: … A receiver attempting to process all the options in such packet would require a lot of resources as TLV processing is notoriously difficult to do efficiently. The potential for this DOS attack exists routers, hosts, and intermediate nodes. Routers are susceptible to the attack using Hop-by-Hop options Sugegsted NEW: … A receiver that attempts to process all the options in such packet would incur significant processing (e.g., TLV processing can be difficult to efficiently implement). This DOS vulnerability could exist in routers, hosts, and intermediate nodes. --- - I think this text could be improved - Elsewhere I don’t think the is called a “receiver”? - The words “lot of” and “notoriously” both would be better replaced. (see example new starting text). ===END===_______________________________________________ Tsv-art mailing list -- tsv-art@xxxxxxxx To unsubscribe send an email to tsv-art-leave@xxxxxxxx
I've personally said before on the 6man list, that I do like the
idea to provide practical guidance for hosts, and that basing this
on experience learned in Linux could be a great way to do this.
The review is provided to help our AD. I suggest you speak to
your responsible AD if you wish to revise the I-D.
Best wishes,
Gorry
-- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
