[PATCH net-next 3/4] ipv6: Reference RFC8504 for limits in padding and EH

[Tom Herbert <tom@herbertland.com>]

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 <tom@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