Subject: Proposed text in Section 4.8. "Defining New Extension Headers and Options"

From: Bob Hinden <[email-masked]>
Date: Wed, 26 Apr 2017 11:38:01 -0700

Hi,

Based on the comments and IESG discusses, I clarified the text in Section 4.8 about defining new IPv6 extension headers.  The proposed text is much closer what was in RFC6564 that updated RFC2460.

CURRENT and NEW text is below.

Comments?

Bob

   CURRENT

   Defining new IPv6 extension headers is not recommended.  There has to
   be a very clear justification why any new extension header is needed
   before it is standardized.  Instead of defining new Extension
   Headers, it is recommended that the Destination Options header is
   used to carry optional information that must be examined only by a
   packet's destination node(s), because they provide better handling
   and backward compatibility.

   NEW

   Defining new IPv6 extension headers is not recommended, unless no
   existing IPv6 extension header can be used by specifying a new option
   for that existing IPv6 extension header.  Any proposal to create or
   specify a new IPv6 extension header must include a detailed technical
   explanation of why no existing IPv6 extension header can be used in
   the document proposing the new IPv6 extension header.

   Instead of defining new Extension Headers, it is recommended that the
   Destination Options header is used to carry optional information that
   must be examined only by a packet's destination node(s), because they
   provide better handling and backward compatibility.

   END NEW

   If new Extension Headers are defined, they need to use the following
   format:

   . . . . . .

---

From: Roland Bless <[email-masked]>
Date: Wed, 26 Apr 2017 22:48:04 +0200

Hi Bob,

> CURRENT and NEW text is below.

Sound good to me!

Roland

> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Tim Chown <[email-masked]>
Date: Thu, 27 Apr 2017 09:02:36 +0000

Hi Bob,

> On 26 Apr 2017, at 19:38, Bob Hinden <[email-masked]> wrote:
> 
> Hi,
> 

That text is very close to section 3 of RFC6564, which is fine.

>   provide better handling and backward compatibility.

That’s fine for Destination options. 

But I think the ordering of the text in 4.8 would be a little odd though, so I’d suggest taking what you propose (NEW text) and reordering section 4.8 as follows (NEW NEW) so that the text talks at a high level, then about HbH, then about destination options, adding “In particular,” and “Further,” to help the flow:

—

NEW:

4.8.  Defining New Extension Headers and Options

   New extension headers that require hop-by-hop behavior must not be
   defined because, as specified in Section 4 of this document, the only
   Extension Header that has hop-by-hop behavior is the Hop-by-Hop
   Options header.

   New hop-by-hop options are not recommended because nodes may be
   configured to ignore the Hop-by-Hop Option header, drop packets
   containing a hop-by-hop header, or assign packets containing a hop-
   by-hop header to a slow processing path.  Designers considering
   defining new hop-by-hop options need to be aware of this likely
   behaviour.  There has to be a very clear justification why any new
   hop-by-hop option is needed before it is standardized.

   If new Extension Headers are defined, they need to ….

—

NEW NEW:

4.8.  Defining New Extension Headers and Options

   In particular, new extension headers that require hop-by-hop behavior must not be
   defined because, as specified in Section 4 of this document, the only
   Extension Header that has hop-by-hop behavior is the Hop-by-Hop
   Options header.

   Further, new hop-by-hop options are not recommended because nodes may be
   configured to ignore the Hop-by-Hop Option header, drop packets
   containing a hop-by-hop header, or assign packets containing a hop-
   by-hop header to a slow processing path.  Designers considering
   defining new hop-by-hop options need to be aware of this likely
   behaviour.  There has to be a very clear justification why any new
   hop-by-hop option is needed before it is standardized.

  Where a new requirement arises to carry optional information that 
  must be examined only by a packet's destination node(s), instead 
  of defining new Extension Headers, it is recommended that the 
  existing Destination Options header is used to carry such information.  
 (* Add the rationale text back in here if that’s deemed useful; it seems unnecessary? *)

   If new Extension Headers are defined, they need to ….

—

Best wishes,
Tim

---

From: Bob Hinden <[email-masked]>
Date: Thu, 27 Apr 2017 14:45:17 -0700

Tim,

> On Apr 27, 2017, at 2:02 AM, Tim Chown <[email-masked]> wrote:
> 
> Hi Bob,
> 

Good, thanks.

> But I think the ordering of the text in 4.8 would be a little odd though, so I’d suggest taking what you propose (NEW text) and reordering section 4.8 as follows (NEW NEW) so that the text talks at…

See below.

>   If new Extension Headers are defined, they need to ….

I agree that it makes sense to move the general statement first in this section.  How about the following?

Bob

  NEW NEW

   Note: New extension headers that require hop-by-hop behavior must not
   be defined because, as specified in Section 4 of this document, the
   only Extension Header that has hop-by-hop behavior is the Hop-by-Hop
   Options header.

   Instead of defining new Extension Headers, it is recommended that the
   Destination Options header is used to carry optional information that
   must be processed only by a packet's destination node(s), because they
   provide better handling and backward compatibility.

   END NEW NEW

---

From: Tim Chown <[email-masked]>
Date: Fri, 28 Apr 2017 16:06:57 +0000

Hi Bob,

Perfectly happy with what you propose below.

Best wishes,

Tim 

> On 27 Apr 2017, at 22:45, Bob Hinden <[email-masked]> wrote:
> 
> Tim,
>

---

From: Bob Hinden <[email-masked]>
Date: Fri, 28 Apr 2017 09:45:49 -0700

> On Apr 28, 2017, at 9:06 AM, Tim Chown <[email-masked]> wrote:
> 
> Hi Bob,
> 

Thanks,
Bob