[PATCH net-next 1/4] ipv6: Resolve comment that EH processing order is being violated

[Tom Herbert <tom@herbertland.com>]

ipv6_skip_exthdr is preambled with a comment indicating that the
function necessarily violates the extension header processing order
requirements of RFC2460 in order to fulfill requirements of ICMPv6
processing. This patch revises the comment to indicate that the
function is conformant with RFC8200 (which obsoletes RFC2460) on
the basis that later headers are only being parsed and not actually
processed.

Signed-off-by: Tom Herbert <tom@quantonium.net>
---
 net/ipv6/exthdrs_core.c | 23 +++++++----------------
 1 file changed, 7 insertions(+), 16 deletions(-)

diff --git a/net/ipv6/exthdrs_core.c b/net/ipv6/exthdrs_core.c
index 11a43ee..aa025e5 100644
--- a/net/ipv6/exthdrs_core.c
+++ b/net/ipv6/exthdrs_core.c
@@ -27,22 +27,13 @@ EXPORT_SYMBOL(ipv6_ext_hdr);
 /*
  * Skip any extension headers. This is used by the ICMP module.
  *
- * Note that strictly speaking this conflicts with RFC 2460 4.0:
- * ...The contents and semantics of each extension header determine whether
- * or not to proceed to the next header.  Therefore, extension headers must
- * be processed strictly in the order they appear in the packet; a
- * receiver must not, for example, scan through a packet looking for a
- * particular kind of extension header and process that header prior to
- * processing all preceding ones.
- *
- * We do exactly this. This is a protocol bug. We can't decide after a
- * seeing an unknown discard-with-error flavour TLV option if it's a
- * ICMP error message or not (errors should never be send in reply to
- * ICMP error messages).
- *
- * But I see no other way to do this. This might need to be reexamined
- * when Linux implements ESP (and maybe AUTH) headers.
- * --AK
+ * Note that Section 4, RFC8200 specifies "extension headers must be processed
+ * strictly in the order they appear in the packet". This function does skip
+ * over extension headers, however it is only for the purpose of extracting
+ * information about deeper header layers in the packet. Specified protocol
+ * processing is not being doing for scanned headers, hence extension headers
+ * are only being parsed but not processed out of order. Therefore, this
+ * function is conformant with RFC8200.
  *
  * This function parses (probably truncated) exthdr set "hdr".
  * "nexthdrp" initially points to some place,
-- 
2.7.4