On Wed, Nov 27, 2024 at 1:47 AM Gorry Fairhurst via Datatracker
<noreply@xxxxxxxx> wrote:
Reviewer: Gorry Fairhurst
Review result: Not Ready
Hi 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
