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

From: Ron Bonica <[email-masked]>
Date: Fri, 6 Mar 2020 22:45:22 +0000

Please review and comment.

Juniper Business Use Only

-----Original Message-----
From: [email-masked] <[email-masked]> 
Sent: Friday, March 6, 2020 5:41 PM
To: Ron Bonica <[email-masked]>
Subject: New Version Notification for draft-bonica-6man-ext-hdr-update-00.txt

A new version of I-D, draft-bonica-6man-ext-hdr-update-00.txt
has been successfully submitted by Ron Bonica and posted to the IETF repository.

Name:		draft-bonica-6man-ext-hdr-update
Revision:	00
Title:		Inserting, Processing And Deleting IPv6 Extension Headers
Document date:	2020-03-06
Group:		Individual Submission
Pages:		5
URL:            https://www.ietf.org/internet-drafts/draft-bonica-6man-ext-hdr-update-00.txt 
Status:       https://datatracker.ietf.org/doc/draft-bonica-6man-ext-hdr-update/ 
Htmlized:     https://tools.ietf.org/html/draft-bonica-6man-ext-hdr-update-00 
Htmlized:       https://datatracker.ietf.org/doc/html/draft-bonica-6man-ext-hdr-update 

Abstract:
   This document provides guidance regarding the processing, insertion
   and deletion of IPv6 extension headers.  It updates RFC 8200.

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Andrew Alston <[email-masked]>
Date: Fri, 6 Mar 2020 22:59:48 +0000

Thanks Ron,

I would fully support this based on first read – and I am actually extremely glad to see a proposal if this nature appear. I think the passage of this document will certainly clear up a lot of issues and potentially reduce the amount of friction we are seeing because of varying interpretations.

Thanks

Andrew

From: ipv6 <[email-masked]> on behalf of Ron Bonica <rbonica=[email-masked]>
Date: Saturday, 7 March 2020 at 01:46
To: "[email-masked]" <[email-masked]>
Subject: FW: New Version Notification for draft-bonica-6man-ext-hdr-update-00.txt

-----Original Message-----
From: [email-masked] <[email-masked]>
Sent: Friday, March 6, 2020 5:41 PM
To: Ron Bonica <[email-masked]>
Subject: New Version Notification for draft-bonica-6man-ext-hdr-update-00.txt

Name: draft-bonica-6man-ext-hdr-update
Revision: 00
Title: Inserting, Processing And Deleting IPv6 Extension Headers
Document date: 2020-03-06
Group: Individual Submission
Pages: 5
URL: https://www.ietf.org/internet-drafts/draft-bonica-6man-ext-hdr-update-00.txt<https://www.ietf.org/internet-drafts/draft-bonica-6man-ext-hdr-update-00.txt>
Status: https://datatracker.ietf.org/doc/draft-bonica-6man-ext-hdr-update/<https://datatracker.ietf.org/doc/draft-bonica-6man-ext-hdr-update>
Htmlized: https://tools.ietf.org/html/draft-bonica-6man-ext-hdr-update-00<https://tools.ietf.org/html/draft-bonica-6man-ext-hdr-update-00>
Htmlized: https://datatracker.ietf.org/doc/html/draft-bonica-6man-ext-hdr-update<https://datatracker.ietf.org/doc/html/draft-bonica-6man-ext-hdr-update>

Abstract:

The IETF Secretariat

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

---

From: Tom Herbert <[email-masked]>
Date: Fri, 6 Mar 2020 15:24:59 -0800

Ron,

Thanks for the draft!

I suggest to define the term "final destination" as opposed to just
"destination" out of an abundance of clarity. Note that the
Destination address isn't necessarily the address of the final
destination, and similarly Destination Options (before the routing
header) may be processed by nodes other than the final destination.

I don't understand why this particular requirement is needed:
"However, if the packet does not include a Fragment header, the
Authentication header and Encapsulating Security Payload header can be
processed by any segment egress node, including the destination node."

My interpretation of the intent of RFC8200 is that:
- All nodes in the path can process Hop-by-hop options
- Segment egress nodes can process Hop-by-hop options, Destination
Options before routing header, and the Routing header (that is unless
the segment egress node is also the final destination it does not
process any of the packet beyond the routing header)
- Final destinations process all packet headers

"Process" here does not include inserting or deleting extension
headers. It may include modifications that are done on fields
explicitly declared to be mutable.

Tom

On Fri, Mar 6, 2020 at 2:45 PM Ron Bonica
<rbonica=[email-masked]> wrote:
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6

---

From: Ron Bonica <[email-masked]>
Date: Sat, 7 Mar 2020 00:36:18 +0000

Hi Tom,

Thanks for the review. Comments inline.....

                                Ron

-----Original Message-----
From: Tom Herbert <[email-masked]> 
Sent: Friday, March 6, 2020 6:25 PM
To: Ron Bonica <[email-masked]>
Cc: [email-masked]
Subject: Re: FW: New Version Notification for draft-bonica-6man-ext-hdr-update-00.txt

Ron,

Thanks for the draft!

I suggest to define the term "final destination" as opposed to just "destination" out of an abundance of clarity. Note that the Destination address isn't necessarily the address of the final destination, and similarly Destination Options (before the routing
header) may be processed by nodes other than the final destination.

[RB] Fair enough. Maybe final destination or ultimate destination.

I don't understand why this particular requirement is needed:
"However, if the packet does not include a Fragment header, the Authentication header and Encapsulating Security Payload header can be processed by any segment egress node, including the destination node."

My interpretation of the intent of RFC8200 is that:
- All nodes in the path can process Hop-by-hop options
- Segment egress nodes can process Hop-by-hop options, Destination Options before routing header, and the Routing header (that is unless the segment egress node is also the final destination it does not process any of the packet beyond the routing header)
- Final destinations process all packet headers

[RB] You are correct. I will fix this right away.

"Process" here does not include inserting or deleting extension headers. It may include modifications that are done on fields explicitly declared to be mutable.

[RB] Yes. I will clarify that.

Tom

On Fri, Mar 6, 2020 at 2:45 PM Ron Bonica <rbonica=[email-masked]> wrote:
> URL:            https://urldefense.com/v3/__https://www.ietf.org/internet-drafts/draft-bonica-6man-ext-hdr-update-00.txt__;!!NEt6yMaO-gk!U5D_phraIxAwKqMrWDSa87_at2DUci9QUmKtH1rE42HmEbybR6X9Wsq15vGrEd2Y$ 
> Status:       https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-bonica-6man-ext-hdr-update/__;!!NEt6yMaO-gk!U5D_phraIxAwKqMrWDSa87_at2DUci9QUmKtH1rE42HmEbybR6X9Wsq15hjd1VtT$ 
> Htmlized:     https://urldefense.com/v3/__https://tools.ietf.org/html/draft-bonica-6man-ext-hdr-update-00__;!!NEt6yMaO-gk!U5D_phraIxAwKqMrWDSa87_at2DUci9QUmKtH1rE42HmEbybR6X9Wsq15vJvzWAw$ 
> Htmlized:       https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-bonica-6man-ext-hdr-update__;!!NEt6yMaO-gk!U5D_phraIxAwKqMrWDSa87_at2DUci9QUmKtH1rE42HmEbybR6X9Wsq15mbBPBWx$ 
>
>
> Abstract:
> Administrative Requests: 
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6
> __;!!NEt6yMaO-gk!U5D_phraIxAwKqMrWDSa87_at2DUci9QUmKtH1rE42HmEbybR6X9W
> sq15imVyTZZ$

---

From: Gyan Mishra <[email-masked]>
Date: Mon, 9 Mar 2020 00:49:18 -0400

Ron

I agree this is a much needed update to RFC 8200 to tighten up the
verbiage.  I agree with Tom’s comments on the draft.

In Tom’s comment about destination versus final destination that is
important clarity as far as hop by hop steering with SID copied to DA, you
don’t want the hop by hop DA copied during SRH processing to be confused
with final destination node.  As far final destination in the SR use case
it would be a closed domain being the SP operators core.  However the
customer payload tunneled through the operator domain would actually
terminate outside the Operators domain within the customer network and
could also have an RH that should also follow the RFC 8200 rules as to
final destination of the packet within the customer network.

I think the main use case is for operators and SR but since this is the
IPv6 specification we are updating it should account for all final
 destination use cases for RH processing and what is allowed and what is
forbidden.

Kind regards

Gyan

On Fri, Mar 6, 2020 at 7:36 PM Ron Bonica <rbonica=
[email-masked]> wrote:

> "destination" out of an abundance of clarity. Note that the Destination
> address isn't necessarily the address of the final destination, and
> similarly Destination Options (before the routing
> - Segment egress nodes can process Hop-by-hop options, Destination Options
> before routing header, and the Routing header (that is unless the segment
> egress node is also the final destination it does not process any of the
> packet beyond the routing header)
> "Process" here does not include inserting or deleting extension headers.
> It may include modifications that are done on fields explicitly declared to
> be mutable.
>
> > URL:
> https://urldefense.com/v3/__https://www.ietf.org/internet-drafts/draft-bonica-6man-ext-hdr-update-00.txt__;!!NEt6yMaO-gk!U5D_phraIxAwKqMrWDSa87_at2DUci9QUmKtH1rE42HmEbybR6X9Wsq15vGrEd2Y$
> > Status:
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-bonica-6man-ext-hdr-update/__;!!NEt6yMaO-gk!U5D_phraIxAwKqMrWDSa87_at2DUci9QUmKtH1rE42HmEbybR6X9Wsq15hjd1VtT$
> > Htmlized:
> https://urldefense.com/v3/__https://tools.ietf.org/html/draft-bonica-6man-ext-hdr-update-00__;!!NEt6yMaO-gk!U5D_phraIxAwKqMrWDSa87_at2DUci9QUmKtH1rE42HmEbybR6X9Wsq15vJvzWAw$
> > Htmlized:
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-bonica-6man-ext-hdr-update__;!!NEt6yMaO-gk!U5D_phraIxAwKqMrWDSa87_at2DUci9QUmKtH1rE42HmEbybR6X9Wsq15mbBPBWx$
> >
> >
> > Abstract:
> > Please note that it may take a couple of minutes from the time of
> submission until the htmlized version and diff are available at
> tools.ietf.org.
> >
> > The IETF Secretariat
> >
-- 

Gyan  Mishra

Network Engineering & Technology

Verizon

Silver Spring, MD 20904

Phone: 301 502-1347

Email: [email-masked]

---

From: 神明達哉 <[email-masked]>
Date: Mon, 9 Mar 2020 15:24:33 -0700

At Fri, 6 Mar 2020 22:45:22 +0000,

> 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.

- Section 3.2

   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).

- 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.

- 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".

- 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.

--
JINMEI, Tatuya

---

From: Tom Herbert <[email-masked]>
Date: Mon, 9 Mar 2020 15:48:26 -0700

On Sun, Mar 8, 2020 at 9:49 PM Gyan Mishra <[email-masked]> wrote:
>
> Ron
>
> I agree this is a much needed update to RFC 8200 to tighten up the verbiage.  I agree with Tom’s comments on the draft.
>
> In Tom’s comment about destination versus final destination that is important clarity as far as hop by hop steering with SID copied to DA, you don’t want the hop by hop DA copied during SRH processing to be confused with final destination node.  As far final destination in the SR use case it would be a closed domain being the SP operators core.  However the customer payload tunneled through the operator domain would actually terminate outside the Operators domain within the customer network and could also have an RH that should also follow the RFC 8200 rules as to final destination of the packet within the customer network.
>
> I think the main use case is for operators and SR but since this is the IPv6 specification we are updating it should account for all final  destination use cases for RH processing and what is allowed and what is forbidden.

RFC8200 already uses the "final destination" terminology in several
instances, including this interesting statement that does clarify the
correlation between Destination address and final destination in the
presence of a Routing header at least for fragmentation:

"If a Routing header is present, the Destination Address of concern is
that of the final destination."

Tom
>
> Kind regards
>
> Gyan
>
> On Fri, Mar 6, 2020 at 7:36 PM Ron Bonica <rbonica=[email-masked]> wrote:
>>
>> Hi Tom,
>>

---

From: Gyan Mishra <[email-masked]>
Date: Mon, 9 Mar 2020 20:38:29 -0400

> that of the final destination."

    Good!  I am good with that verbiage.  Thank you for verifying!

> Options before routing header, and the Routing header (that is unless the
> segment egress node is also the final destination it does not process any
> of the packet beyond the routing header)
> headers. It may include modifications that are done on fields explicitly
> declared to be mutable.
> >>
-- 

Gyan  Mishra

Verizon

Silver Spring, MD 20904

Phone: 301 502-1347

---

From: Ron Bonica <[email-masked]>
Date: Tue, 10 Mar 2020 18:17:45 +0000

Jinmei,

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

 Comments inline..

                                   Ron

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

> 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.

[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.

[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

[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

[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

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

--
JINMEI, Tatuya