RFC8504 specifies requirements for applying limits to Hop-by-Hop
and Destination Options extension headers and options (including
padding). Reference this RFC appropriately.
Signed-off-by: Tom Herbert <t...@quantonium.net>
---
include/net/ipv6.h | 9 +++++----
net/ipv6/exthdrs.c | 3 ++-
2 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/include/net/ipv6.h b/include/net/ipv6.h
index daf8086..fd01823 100644
--- a/include/net/ipv6.h
+++ b/include/net/ipv6.h
@@ -54,10 +54,11 @@
/* Limits on Hop-by-Hop and Destination options.
*
- * Per RFC8200 there is no limit on the maximum number or lengths of options in
- * Hop-by-Hop or Destination options other then the packet must fit in an MTU.
- * We allow configurable limits in order to mitigate potential denial of
- * service attacks.
+ * Section 5.3 of RFC8504 describes limits that may be applied by an
+ * implementation to protect a node from excessive extension header options
+ * (for instance, to protect a node from denial of service attacks where
+ * the attacker sends packets filled with tiny options that will be skipped
+ * by a receiver).
*
* There are three limits that may be set:
* - Limit the number of options in a Hop-by-Hop or Destination options
diff --git a/net/ipv6/exthdrs.c b/net/ipv6/exthdrs.c
index fdb4a32..f0e0f7a 100644
--- a/net/ipv6/exthdrs.c
+++ b/net/ipv6/exthdrs.c
@@ -153,7 +153,8 @@ static bool ip6_parse_tlv(const struct tlvtype_proc *procs,
/* RFC 8200 states that the purpose of PadN is
* to align the containing header to multiples
* of 8. 7 is therefore the highest valid value.
- * See also RFC 4942, Section 2.1.9.5.
+ * See also RFC 4942, Section 2.1.9.5, and
+ * RFC 8504, Section 5.3.
*/
padlen += optlen;
if (padlen > 7)
--
2.7.4
