RE: FW: New Version Notification for draft-bonica-6man-ext-hdr-update-00.txt

[Ron Bonica <[e-mail]>]

Jinmei,

Thanks for this thoughtful review. Look for an updated version as soon as the submission tool reopens.

 Comments inline..

                                   Ron


Juniper Business Use Only

-----Original Message-----
From: 神明達哉 <[e-mail]> 
Sent: Monday, March 9, 2020 6:25 PM
To: Ron Bonica <[e-mail]>
Cc: [e-mail]
Subject: Re: FW: New Version Notification for draft-bonica-6man-ext-hdr-update-00.txt

At Fri, 6 Mar 2020 22:45:22 +0000,
Ron Bonica <rbonica=[e-mail]> wrote:

> Please review and comment.

I've noticed the latest version is 02, which I've read and on which I'm making comment below.

First off, I think a clarification like this draft is necessary to prevent future confusion.

- Section 2 (and throughout the draft)

   o  Destination node - An IPv6 destination node receives an IPv6
      packet and delivers its payload to an upper-layer protocol.  If a
      packet contains a Routing header, its destination address may
      represent an interface that belongs to a node other than the
      destination node.

   This definition is clear, but I think it's better to say something
   like "final destination (node)" or "ultimate destination (node)",
   since the word "destination" has been one major point of the entire
   confusion.  If we keep the phrase of bare "destination" (even if
   the definition given in this section is clear without ambiguity)
   I'm afraid it could still confuse not-so-careful readers.

[RB] I agree. In the definition that you quote above, we should change the term "Destination Node" to "Final Destination Node" or "Ultimate Destination node.

[RB] However, this exposes a larger problem. Today, RFC 8200 uses the term "destination node" in an inconsistent manner. In Sections 2 and 3, the term refers to the ultimate destination. In Section 4, it refers to segment endpoints. 

[RB] I wonder if we should clean this up while we are thinking about the problem.

   packet's delivery path.  The following headers can be processed by
   any segment egress node, including the destination node:

   o  Destination Options header.
   [...]

   A destination options header can be "processed" by an intermediate
   segment egress node only when it appears before a routing header.
   (I'm not sure if this should be noted in the text of the draft,
   though).

[RB] Note 2 in Section 4.1 makes this clear. But since you and Fernando both raised the same point, maybe we should say it again.


- Section 3.2

   The following headers can be processed by the destination node only:
   o  The Fragment header.
   o  The Authentication header.
   o  The Encapsulating Security Payload header.

  I'm not sure if we need to list these explicitly.  While it may be
  quite unlikely in practice, it's still possible we have a new type
  of extension header.  If and when that happens this list will become
  non-comprehensive.  Secondly, if these headers happen to appear
  before a routing header, it's not necessarily prohibited for these
  headers to be "processed" in segment egress nodes (including
  intermediate ones) of the routing header.  In practice, that would
  cause some kind of trouble (like AH verification failure) and would
  be useless, but in my understanding it's not necessarily prevented
  by RFC8200.  If we want to cover such corner cases we'll probably
  need to discuss whether the header ordering follows the recommended
  order as described in Section 4.1 of RFC8200, and/or discuss such
  weird cases separately.

  I'm not necessarily opposed to it, but if the main focus is to fix
  the obvious bug of RFC8200, by essentially separating "inserted, or
  deleted" from this text:

    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.

  and clarifying "EHs are not inserted or deleted until the packet
  arrives at the final destination node", then I'm not sure if we'd
  rather touch this tricky side issue.

[RB] I understand what you are saying. Bob Hinden made the same comment in a private email. I will try to reword that section, making a distinction between per-hop, per-segment, and per-path options without enumerating them.

- Section 3.2

  As for the word "processing", I agree it's ambiguous and I'm not
  very happy about it, but I'm not sure if this draft should try to
  clarify it beyond that it doesn't include "inserting or deleting".

[RB] I understand what you are saying. Brian Carpenter made the same comment in a private email. I will add two definitions in the terminology section, one for EH processing, and one for EH inspection.

- Section 4

   o  Semantic corruption - Insertion of an extension header can change
      the meaning of a packet.
   o  Semantic corruption - Deletion of an extension header can change
      the meaning of a packet.

  Can these be more specific?  "change the meaning of a packet" sounds
  vague, and in some sense it could also be the case, e.g., in
  "processing" a HbH or Destination options header.

[RB] Agree. Look for more text in the next revision.

--
JINMEI, Tatuya