Proposed revised Extension Header text for rfc2460bis

[Bob Hinden <[e-mail]>]

Hi,

After reading through the discussion about this text in Section 4, I have some new text to propose.  I think this is significantly improved and should resolve many of the issued raised.

Changes include separate description of behaviors extension headers and the hop-by-hop option header, remove “examine” from the first paragraph.  I removed “examine” because I am convinced it’s not sustainable to say a node can’t examine extension given how widespread this behavior is.  I also removed the reference to RFC7045 because examine is removed.  RFC7045 is referenced in the recently updated Security Considerations section.

I removed the “including the source and destination nodes” text from the paragraph on the hop-by-hop options header because I don’t think we need to mention the source, and there is a whole paragraph describe what happens at the destination node.  I also added the text about from the first paragraph about reaching the destination to the hop-by-hop header paragraph.

I also moved (without change) the “At the Destination node...” text from the first paragraph to a new third paragraph.  It applies to all extension headers.

CURRENT and NEW text below.  Please review and comment.

Bob


   CURRENT

   With one exception, extension headers are not examined, processed,
   inserted, or deleted by any node along a packet's delivery path,
   until the packet reaches the node (or each of the set of nodes, in
   the case of multicast) identified in the Destination Address field of
   the IPv6 header.  Note: If an intermediate forwarding node examines
   an extension header for any reason, it must do so in accordance with
   the provisions of [RFC7045].  At the Destination node, normal
   demultiplexing on the Next Header field of the IPv6 header invokes
   the module to process the first extension header, or the upper-layer
   header if no extension header is present.  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.

   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.

   NEW

   Extension headers (except for the Hop-by-Hop Options header) are not
   processed, inserted, or deleted by any node along a packet's delivery
   path, until the packet reaches the node (or each of the set of nodes,
   in the case of multicast) identified in the Destination Address field
   of the IPv6 header.

   The Hop-by-Hop Options header is not inserted or deleted, but may be
   examined and processed by every node along a packet's delivery path,
   until the packet reaches the node (or each of the set of nodes, in
   the case of multicast) identified in the Destination Address field of
   the IPv6 header.  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.

   At the Destination node, normal demultiplexing on the Next Header
   field of the IPv6 header invokes the module to process the first
   extension header, or the upper-layer header if no extension header is
   present.  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.

   END NEW