Possible ambiguity of Hop-by-Hop Options header processing text in draft-ietf-6man-rfc2460bis-08

"C. M. Heard" <heard@pobox.com> Sun, 19 February 2017 23:15 UTC

DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=mime-version :from:date:message-id:subject:to:content-type; q=dns; s=sasl; b= v5hbMIGT++i5uubapdpHY/xIer7JuVYY/fQMwQITa6SXYjDmFtbORqK7Wmz7aZD7 Tr7zQCZuICbD/0Kk0U61We1NToHeX6jnyn5uSwMIfHthl9mDjjdgfjSjiGZr5feK g/+kOXqzZdqRTcLYaPKa/Q7N2PJujQptvDw+AaRBs1g=
MIME-Version: 1.0
From: "C. M. Heard" <heard@pobox.com>
Date: Sun, 19 Feb 2017 15:14:40 -0800
Message-ID: <CACL_3VHC3sx5=E4uk3+6-LR-JqXXMwF4cmMuJH-goipBUDX7fw@mail.gmail.com>
Subject: Possible ambiguity of Hop-by-Hop Options header processing text in draft-ietf-6man-rfc2460bis-08
To: IETF <ietf@ietf.org>, 6man WG <ipv6@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/VKJWqpFe1LjKN067rk3R-x4fdkk>
Precedence: list

Greetings,

While looking at something else, it occurred to me that there is a
possible ambiguity in the following text on Hop-by-Hop Options
header processing in draft-ietf-6man-rfc2460bis-08:

   The exception referred to in the preceding paragraph is the Hop-by-
   Hop Options header, which carries information that may be examined
   and processed by every node along a packet's delivery path, including
   the source and destination nodes.  The Hop-by-Hop Options header,
   when present, must immediately follow the IPv6 header.  Its presence
   is indicated by the value zero in the Next Header field of the IPv6
   header.

   NOTE: While [RFC2460] required that all nodes must examine and
   process the Hop-by-Hop Options header, it is now expected that nodes
   along a packet's delivery path only examine and process the Hop-by-
   Hop Options header if explicitly configured to do so.

The ambiguity: was the note intended to apply to every node along a
packet's delivery path, *including* the source and destination nodes?
Or was it intended to apply *only* to intermediate nodes?  It seemed
clear to me from the discussions in 6man that the issues that motivated
the note applied to forwarding nodes, not to end nodes, which are
expected to process every extension header present in a packet,
discarding it if they cannot do so.  It would seem odd not to expect
the HBH Options header to be processed given that we expect all other
headers to be processed, including the Destination Options header.

On that basis I would like to suggest changing the note as follows:

   NOTE: While [RFC2460] required that all nodes must examine and
   process the Hop-by-Hop Options header, it is now expected that nodes
   along a packet's delivery path, other than the source and destination
   nodes, will examine and process the Hop-by-Hop Options header only if
   explicitly configured to do so.

Apologies for not catching this during the WG discussion.

Regards,

Mike Heard

Possible ambiguity of Hop-by-Hop Options header p… C. M. Heard
Re: Possible ambiguity of Hop-by-Hop Options head… Joe Touch