Subject: Alvaro Retana's Discuss on draft-ietf-6man-rfc2460bis-09: (with DISCUSS and COMMENT)

From: Alvaro Retana <[email-masked]>
Date: Fri, 07 Apr 2017 11:39:56 -0700

Alvaro Retana has entered the following ballot position for
draft-ietf-6man-rfc2460bis-09: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-6man-rfc2460bis/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

First off, this DISCUSS is NOT about questioning the rough consensus
calls that the responsible Chair and AD have made, or wanting to change
them, but about clarifying to avoid misinterpretations.

Given the ongoing discussion about Extension Headers and controlled
domains (for example [1] and [2]), the text should be very specific on
what is expected and where.  Because it is not, I think that this
document is teetering along the line of having a "high degree of
technical maturity", and not being ready for Internet Standard
[rfc6410].

Without further clarifications and guidance, this document also brings on
unanticipated second order effects [rfc3439] that can impact the
direction, or even the viability, of future work in the IETF. 
Specifically, a straight forward interpretation of the text in Section 4
is the absolute prohibition to process, insert or delete EHs -- but
discussion on the 6man mailing list seems to point at an understanding
that the conditions inside a controlled domain may be different, for
example (from Brian Carpenter [3]):

=====
I've tried to say this before but I'm not sure people are getting it: 

RFC2460bis, if approved as is, draws a line in the sand *for
interoperability across the whole Internet*. There are reasons for this -
PMTUD in any form, any future replacement for the unsuccessful IPsec/AH,
and all the problems of deploying extension headers that are understood
by some nodes and not by others. 

There is no reason why a subsequent standards-track document cannot allow
header insertion (and removal) within finite domains where the above
issues do not apply. In fact, an improved version of
draft-voyer-6man-extension-header-insertion-00 could become exactly
that.

=====

[N.B.: I'm not implying that Brian's opinion represents consensus, that
is not my call to make.]

I'm pointing at an opinion (which I agree with) that recognizes the need
to differentiate between contexts -- but the current text in rfc2460bis
doesn't do that.  I believe that this issue is significant (as reflected
by the ongoing discussions) that that it should be resolved (by
clarifying the text) before proceeding with the publication of this
document as an Internet Standard. 

To summarize, the text in this document has the second order effect of
not leaving a clear path forward for extensions to IPv6 so that they
adhere to the protocol's architecture, specially when applied to a
controlled domain.  At a minimum, I would like to see a clear path
forward, whether that is in the form of an update for use of extensions
in controlled domains, or a statement that this document just applies to
IPv6 traffic intended to cross the Internet (as suggested at the 6man
meeting in Chicago [4])...  My opinion is that this document should not
be published as an Internet Standard until the remaining open discussions
are explicitly resolved and this document reflects that resolution.

[1]
https://mailarchive.ietf.org/arch/msg/ipv6/UI0PfqrWco4Hpbvm8keGR8FabRg/?qid=9a6ba8e9777114e24a1e964336ed78f1
[2]
https://mailarchive.ietf.org/arch/msg/ipv6/OrLYxKumiKWLHGkeNamhq9pxutQ/?qid=63c159fe41c18653d9dc0be609f9e97f
[3]
https://mailarchive.ietf.org/arch/msg/ipv6/REez0-lbebpo-Xem-xX_sWV0pf4/?qid=5cdab6c6085795129802ab622bb4159f
[4] https://www.ietf.org/proceedings/98/minutes/minutes-98-6man-00

==========

Related to the above, I also want to point out the lack of clarity in the
text in Section 4. (IPv6 Extension Headers), which leaves itself open to
interpretation and should be cleaned up.

(A)  The main piece of text that has been discussed now reads:

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

While the first sentence seems clear on what this document wants
forwarding nodes to do (or not), there are two notes that define
exceptions: any forwarding node can examine the headers "for any reason",
and, the Hop-by-Hop Options header doesn't really have to be examined and
processed by everyone.

This text needs some more work to at least not contradict itself: there
is more than one exception, and they are not absolute, anyone can examine
the headers "for any reason"...

(B)

As it stands, the note about the changed expectations for the Hop-by-Hop
options header opens a significant door to work around the "limitations"
of other options.  For example, it would be relatively straight forward
to define a new Hop-by-Hop option to carry any type of information that
could then be "examined, processed, inserted, or deleted by any node
along a packet's delivery path".  In the world of controllers and
programmatic access to forwarding nodes, changing the explicit
configuration on the fly to customize which nodes do what, is trivial.

Is that the intent of this document, to provide a generic mechanism for
cases that may need extension headers to be "examined, processed,
inserted, or deleted by any node along a packet's delivery path"?  Will
the WG/IETF be in a position to charter, adopt and/or publish these types
of documents?  I ask this question not only in the context of my concerns
expressed above, but also because the definition of the Hop-by-Hop Option
would seem to be able to handle anything ("used to carry optional
information that may be examined and processed by every node along a
packet's delivery path" - I didn't see any constraints), even if (for
example) the Routing Header "is used by an IPv6 source to list one or
more intermediate nodes to be "visited" on the way to a packet's
destination" -- so it makes me wonder whether using the Hop-by-Hop
Options header to carry (for example) routing information so that it can
be "examined, processed, inserted, or deleted by any node along a
packet's delivery path" would pass the bar set in Section 4.8. (Defining
New Extension Headers and Options):

   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.

In the context of a controlled domain, it should be relatively easy for
the operator to account for those issues.  So my interpretation of
whether a Hop-by-Hop option is ok to carry (for example) routing
information is a strong "Yes!".  Whether my interpretation is what was
intended or not, I believe the overall text could benefit from more
clarity.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Appendix B. (Changes Since RFC2460) mentions that the text was revised
based on updates from several other RFCs which Updated rfc2460.  I didn't
check all the details, but if the updates were incorporated in this
document, why are those RFCs not marked as being Obsolete?  Is there any
value left in them?

---

From: Fernando Gont <[email-masked]>
Date: Sat, 8 Apr 2017 00:21:49 +0100

Alvaro,

> technical maturity", and not being ready for Internet Standard

Why should any talk on EH insertion affect this document being ready for IS?

Actually, it's quite the opposite: the experience we have with IPv6 is
with "IPv6 'as is'" (i.e.,an end to end protocol that obviously does not
allow for EH insertion). Opening the door to EH insertion would make
this document, by definition, not ready for IS -- and actually, not even
suitable for 6man (which is expected to be about maintaining IPv6,
rather than about applying radical changes).

So this document is clarifying what IPv6 has always been: EHs cannot not
inserted by intermediate nodes.

I personally don't get why the future plans of a vendor should
essentially rule 6man to fundamentally change an end-to-end protocol
(IPv6) into a...whatchamacallit, or be a show stopper during IESG review.

> direction, or even the viability, of future work in the IETF. 

An Architecture will clearly limit and delineate what you can and what
you can't do. If you can do anything that you please, then that's an
indication that you don't really have an architecture.

> example (from Brian Carpenter [3]):

If you agree with the IETF LC (as oted), I'm not sure why *opinions*
verted into the mailing list (*not* wg consensus of any sort) that
happened *after* the IETF LC should affect this document moving forward.

[...]
> document as an Internet Standard. 

As a wg participant, I strongly oppose to that. rfc2460bis specifies
IPv6 -- an end to end protocol. EH insertion has nothing to do with
that. In fact, it implies a radical change to the architecture. So I'm
not sure why we're discussing what seems to be "yet another possible
loophole so that a given vendor can do what it has in its plans".

Please note: 6man decided to accept
draft-ietf-6man-segment-routing-header  on the condition that any
suggestions/specification of EH insertion were removed. That, together
with the IETF LC should be an indication regarding what seems to have
been the consensus on the topic.

I'm puzzled why any sort of ongoing discussion, taig place past IETF LC,
and on a very radical change to the protocol and architecture should
have an effect on rfc2460bis being moved forward.

> are explicitly resolved and this document reflects that resolution.

The onus is on folks wanting to change the current state of affairs.
Changing IPv6 (an end-to-end protocol) to allow for EH insertion is
essentially a very radical change... not only to the protocol, but even
to the architecture.

[...]
> along a packet's delivery path". 

Yes, the text is misleading, and should be improved. I pointed this one
to Brian and Suresh off-list, based on comments by Ivan Arce (CCed). The
text needs to be improved, so that this is not seen as a yet another
loophole for suggesting that H insertion is allowed in IPv6 -- which was
certainly not the intent.

AFAICT, in most cases rfc2460bis incorporated the changes, but didn't
reproduce the rationale. Hence, at least the "rationale for the changes"
is the value left in them, I'd say.

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 9 Apr 2017 01:11:40 +1200

> indication that you don't really have an architecture.

Actually is is the proposal to allow header insertion that risks
unanticipated effects; the draft simply consolidates the current
simple interpretation of RFC 2460. Header insertion would be added
complexity, exactly what RFC 3439 is about.
 
> happened *after* the IETF LC should affect this document moving forward.

Firstly, my opinion is indeed not part of the consensus; I fully support
the WG consensus to publish this draft as IS. It *is* my opinion that
after doing so, we should carefully examine proposals to define *exceptions*
to the ban on header insertion.

I have proposed a small clarification in the Introduction to make it
clear that the scope of this draft is interoperation across the Internet
as  whole. I believe that completely answers Alvaro's point.

>> are explicitly resolved and this document reflects that resolution.

As I understand the rules on promotion to IS, we cannot add new, untested
features to the protocol. That means that adding header insertion is
out of the question. All that is actually proposed is clarifying the
intention, which was badly drafted in RFC 1883 and not corrected in
RFC 2460.
 
> certainly not the intent.

I don't see that. The text says that HbH options may be examined and
processed; it does not say that they may be inserted or deleted. But
it would do no harm to add a 'must not' I guess.

The other tiny change would be to qualify the "Note:..." by writing
"Note: If an intermediate forwarding node _nevertheless_ examines
an extension header for any reason,...". That would eliminate the
minor inconsistency that the text refers to "one" exception.

> is the value left in them, I'd say.

Exactly.

Regards
    Brian

---

From: Fernando Gont <[email-masked]>
Date: Sun, 9 Apr 2017 12:11:38 +0100

Hi, Brian,

Some additional comments about specific parts (I've omitted everything
else, since we're in agreement :-) )...

>> On 04/07/2017 07:39 PM, Alvaro Retana wrote:
[....]
> as  whole. I believe that completely answers Alvaro's point.

Since you have no way of ensuring that packets from such domain will not
leak out that domain, you cannot really pretend that "I can break the
protocol in anyway I please, since it's my own personal domain" --
actually, you can... but you don't need a standard for that.

So any of such proposals should be evaluation considering that packet
may leak out (plan for the worst, expect for the best).

That's not an argument against EH insertion but rather:

* Accept that EH insertion is a modification to IPv6 (as opposed to
pretending that there are loopholes that allow for it)

* Evaluate what's the damage in case packets leak out of such domain

* Evaluate if there are alternative ways of ng the same thing, without
the aforementioned risks (e.g., tunelling)

* IMO, IETF can be assumed to standardize *I* protocols which, unless
otherwise specified, are expected to operate over the Internet. There's
no need to say/clarify that. And in fact, that might trigger folks
assuming that there's a shortcut to modify or break protocols by simply
defining an appropriate "domain".

Folks coming with a proposal about EH insertion need not be any more
special as any other folks bringing any other proposed modification to IPv6.

i.e., evaluation of such proposals would seem to me like normal
operation of the wg, rather than something that we've to agree on that
we're going to do.

Exactly.

> minor inconsistency that the text refers to "one" exception.

The text currently says:

   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.

That is certainly misleading, since the exception is only about
"examined and processed", but not about "inserted or deleted".

The text should be unfolded such that it is clear that the exception
only has to do with HBH being examined and processed, anout not about
HBH being inserted or deleted.

Thanks!

Cheers,

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 10 Apr 2017 03:23:27 +1200

On 09/04/2017 23:11, Fernando Gont wrote:
> leak out that domain,

Well, that's exactly why we would need a detailed specification for
how the boundary of the "controlled domain" would work. That's clearly
new work.

> you cannot really pretend that "I can break the

An interesting aspect is "who gets hurt?" I think the answer is that
only users inside domains that insert headers will get hurt, if
such packets escape and are dropped. But that also needs detailed
analysis.
> no need to say/clarify that.

Well, I looked for that in the rules for Internet Standard (RFC 6410)
and didn't find it. That's why I suggested adding it to 2460bis -
exactly because the Internet Protocol is *above all* the standard that
is expected to operate over the Internet.

But if you are correct, Alvaro's DISCUSS is simply wrong: the scope is
by definition the Internet, so by definition locally inserted or deleted
extension headers are out of scope for this document. My extra words are
only intended to confirm that logic. If we don't need them, so much
the better.

> And in fact, that might trigger folks

Don't worry, plenty of people assume that anyway :-(.

> operation of the wg, rather than something that we've to agree on that

I agree. Once we get rfc2460bis in the RFC Editor queue, of course.
 
>>>> controlled domain.

Alvaro: Correct, and that is intentional. The *intention* is to forbid
insertion of extension headers in the Internet.

>>>> At a minimum, I would like to see a clear path
>>>> in controlled domains, 

I think that is clearly in breach of the rule in RFC6410:

"(3) There are no unused features in the specification that greatly
     increase implementation complexity."

because it would be a new feature of the protocol that has definitely
not seen "widespread deployment and successful operational experience"
as required by rule (1) in RFC6410.

>>>> or a statement that this document just applies to
>>>> meeting in Chicago [4])...  

See above - Fernando and I have exactly opposite opinions on this.

   Brian

>>>> My opinion is that this document should not

---

From: "Stefano Previdi (sprevidi)" <[email-masked]>
Date: Sun, 9 Apr 2017 19:54:26 +0000

> On Apr 8, 2017, at 3:11 PM, Brian E Carpenter <[email-masked]> wrote:
> 
> the WG consensus to publish this draft as IS.

I’m not sure we have such consensus. We _had_ consensus on another text that has been later removed.

s.

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

---

From: Suresh Krishnan <[email-masked]>
Date: Mon, 10 Apr 2017 03:03:32 +0000

Hi Alvaro,
  Thanks for your comments. Please find responses inline.

> On Apr 7, 2017, at 2:39 PM, Alvaro Retana <[email-masked]> wrote:
> 

I read Brian’s comments and I am in agreement with them, but I think the message is subtly different from your understanding. This is how I see it. 

=> If someone comes up with a mechanism to safely do header insertion and documents how to do it, that document can safely progress. This can be done in a controlled domain as long as the proponents are willing to address the concerns that have been brought up and any breakage does not affect any unmodified nodes outside the controlled domain. 

Is this the same way you see it or is there a difference?

> the headers "for any reason”…

Right. I think the examine piece could use some rewording to merge with the RFC7045 exception.

> intended or not, I believe the overall text could benefit from more

My personal opinion is also Yes, as long as the Hop-by-hop option header is inserted into a packet originated in the controlled domain (such as the mechanism specified in draft-ietf-6man-segment-routing-header-06 <https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-06>).

There is a lot of rationale and background that the WG decided not to fold into this document. Lot of these updates documents have led to a few sentences with a pointer back to the other documents for more info and applicability. e.g. RFC6935 allowed UDP checksums to be zero and RFC6936 explains applicability, issues and design principles to consider when zero UDP checksums can be used. They resulted in a few sentences and a pointer for further info. That is why they cannot be obsoleted.

Thanks
Suresh

---

From: Tim Chown <[email-masked]>
Date: Mon, 10 Apr 2017 08:52:12 +0000

Hi,

> On 10 Apr 2017, at 04:03, Suresh Krishnan <[email-masked]> wrote:
> 
> Hi Alvaro,

One way to improve the RFC7045 “contradiction” in the 2460-bis text would be to rearrange the text to lift out the RFC7045 reference such that it follows the text about the HbH option header, adding an example of inspecting the payload, which is the main rationale for such inspection stated in RFC7045. 

Old:

   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.

   and processed by every node along a packet's delivery path, including

New:

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

   and processed by every node along a packet's delivery path, including

   NOTE: If any other intermediate forwarding device needs to examine
   an extension header for any reason, e.g., to traverse the extension
   header chain to inspect the transport header of a packet, it must do so in 
   accordance with the provisions of [RFC7045]. 

The question then would be the specific wording of that last paragraph.

Tim

---

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Mon, 10 Apr 2017 13:38:59 +0000

On 4/9/17, 11:23 AM, "Brian E Carpenter" <[email-masked]> wrote:

Brian/Fernando:

Hi!

As I tried saying before, my DISCUSS is not about having this document allow EH insertion.

I just want the text to be clear.  The fact that there is consensus on the current text doesn’t mean that it is clear.  The one thing that is clear to me is that there are multiple ways of interpreting the current text – and even what people say about it.

> only intended to confirm that logic. If we don't need them, so much

We all know that the mission of the IETF is to “make the Internet work better” [rfc3935] – here is what I think is the relevant definition in this case (from Section 2. (Definition of Terms)):
   The Internet: A large, heterogeneous collection of interconnected
      systems that can be used for communication of many different types
      between any interested parties connected to it.  The term includes
      both the "core Internet" (ISP networks) and "edge Internet"
      (corporate and private networks, often connected via firewalls,
      NAT boxes, application layer gateways and similar devices).  The
      Internet is a truly global network, reaching into just about every
      country in the world.
      The IETF community wants the Internet to succeed because we
      believe that the existence of the Internet, and its influence on
      economics, communication, and education, will help us to build a
      better human society.

Starting from that definition, and please correct me if my interpretation is wrong, “expected to operate over the Internet” (from Fernando above) really points to the “core Internet”, right??

Yes, it is understood that the IETF works on protocols for “the Internet”, but “the Internet” really has two parts, one of them includes (among other things) what I’ve been calling a controlled domain (aka private network).

I’m then looking for a clarification on the applicability of rfc2460bis – something like (to paraphrase Brian): this document applies to packets intended to traverse the “core Internet”.

I am not looking for a blanket statement about insertion/deletion of EHs.  Quoting Suresh from this thread:

On 4/9/17, 11:03 PM, "Suresh Krishnan" <[email-masked]> wrote:

> => If someone comes up with a mechanism to safely do header insertion and 
> documents how to do it, that document can safely progress. This can be done in a 
> controlled domain as long as the proponents are willing to address the concerns 
> that have been brought up and any breakage does not affect any unmodified nodes 
> outside the controlled domain. 

For clarity, I would add that “safely progress” really means that 6man can consider it, and if adopted and consensus is reached, then it could be published.  I agree with that.

Back to the original text of my DISCUSS.  By saying that “Without further clarifications and guidance, this document also brings on unanticipated second order effects [rfc3439] that can impact the direction, or even the viability, of future work in the IETF.” … I meant that (without clarifying), it is very easy to assume that there are no exceptions to what is specified in rfc2560bis.   While it may be that everyone is in wild agreement about the applicability (to the “core Internet”) and whether others in the future can “safely progress” a different proposal, I want it documented so we don’t have to chase down old threads and argue about the intention of a document…  

Thanks!

Alvaro.

---

From: "Stefano Previdi (sprevidi)" <[email-masked]>
Date: Mon, 10 Apr 2017 13:45:46 +0000

Hi Suresh,

> On Apr 10, 2017, at 5:03 AM, Suresh Krishnan <[email-masked]> wrote:
> 
> Hi Alvaro,

if you can reflect the above in the current text of rfc2460bis, then I think it would really help finding the consensus we don’t have today.

s.

> My personal opinion is also Yes, as long as the Hop-by-hop option header is inserted into a packet originated in the controlled domain (such as the mechanism specified in draft-ietf-6man-segment-routing-header-06).
> 
>> 
>>

---

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Mon, 10 Apr 2017 13:53:50 +0000

Tim:

Hi!

The initial sentence mentions 4 actions: examine, process, insert, or delete.  

The text already says that any node can examine the headers “for any reason”, according to [rfc7045].  So maybe take that out as part of the original 4.

I do have an additional clarity question.  What does “process” mean?  Does it include a “change en-route”?    I’m asking because Section 4.2. (Options) says that “the Hop-by-Hop Options header and the Destination Options header” has an option bit that indicates “whether or not the Option Data of that option can change en-route to the packet's final destination”.  I’m assuming that to change the data the transit node has to not just “examine” (which I think means “look at”), but also (at least) “process” the EH as well.   If to “process” includes the ability to “change en-route”, then it looks like the Destination Option may also be an exception…

I don’t think your proposed text does much to clarify…at least not for me. ☹

Thanks!

Alvaro.

On 4/10/17, 4:52 AM, "Tim Chown" <[email-masked]> wrote:

Hi,

Old:

New:

   

Tim

---

From: Tim Chown <[email-masked]>
Date: Mon, 10 Apr 2017 16:09:02 +0000

Hi Alvaro,

> On 10 Apr 2017, at 14:53, Alvaro Retana (aretana) <[email-masked]> wrote:
> 
> Tim:
> 
> Hi!
> 

I think most people always assumed process included inserting and removing headers, but equally some people argue that strictly examining involves some form of processing.

> I don’t think your proposed text does much to clarify…at least not for me. ☹

It’s tricky, without rewriting more text than was originally desired.  It would good for the text to be explicit, and non-contradictory.

Tim

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 11 Apr 2017 08:24:35 +1200

Excuse front posting, but the interleaving is getting a bit distracting in itself.

My considered opinion is that pretending to forbid "examine" is just laughable,
since we know that middleboxes make it their job to examine packet headers. 
So it's pointless to state it; take it out (but leave in the reference to 7045).

The word "process" is too vague - and has been too vague since RFC 1883.
So take that out too. (Clearly, a middlebox that can examine a header
can process it - but so what? That doesn't affect the contents of the
packet.)

What we can meaningfully prohibit in the context of Internet-wide interop
is "insert, modify or delete".

Regards
   Brian

---

From: Fernando Gont <[email-masked]>
Date: Mon, 10 Apr 2017 22:56:15 +0100

Alvaro,

I'll top post because it seems we're arguing about unnecessary details
and missing the high-order bit:

6man is meaning to progress RFC2460 to IS. RFC2460 specifies IPv6. IPv6
applies everywhere. There has never been an applicability statement for
IPv6 because, by definition, it's an Internet protocol (even the name
claims that!). For that reason, I think there is no need for any
applicability statement, and, in fact, that would be wrong.

Having a discussion in which 6man seems to have to sign a contract that
EH-insertion will be "doable" seems unnecessary, off-topic, and plain
wrong (since EH insertion has never been a 6man wg item, and it probably
doesn't even fall within 6man's charter). I don't even know why it's
being brought up in this discussion.

To make the point crystal clear: a document under IESG evaluation meant
to be progressed to IS is being stopped because an *individual* proposal
to do EH insertion (that has never had wg consensus) would be ruled
out/banned. I think that's very bad.

Anything related to EH insertion is not a discussion that should take
place in the context of this document, because IPv6 has never
accommodated EH insertion, and what 6man is currently doing is
progressing the existing IPv6 spec to IS.

It seems to me that were wasting a lot of wg energy for the sake of
pleasing a specific vendor. And that's bad.

P.S.: (Off-topic) Funny exercise for folks playing with the idea of an
applicability statement: Which std should I implement or try to comply
with for, e.g., link-local traffic. -- no, not rfc2460bis, since your
applicability statement would make it *not* apply for link-local
traffic. (Your options are to cherry-pick what applies and what not, or
publish different "versions" of IPv6, with complementary applicability
statements).

Thanks,
Fernando

On 04/10/2017 02:38 PM, Alvaro Retana (aretana) wrote:
> I just want the text to be clear.  The fact that there is consensus
> on the current text doesn’t mean that it is clear.  The one thing
> that is clear to me is that there are multiple ways of interpreting
> the current text – and even what people say about it.
> 
>>> * IMO, IETF can be assumed to standardize *I* protocols which,
>>> unless otherwise specified, are expected to operate over the
>>> Internet. There's no need to say/clarify that.
>> 
>> Well, I looked for that in the rules for Internet Standard (RFC
>> 6410) and didn't find it. That's why I suggested adding it to
>> 2460bis - exactly because the Internet Protocol is *above all* the
>> standard that is expected to operate over the Internet.
>> 
>> But if you are correct, Alvaro's DISCUSS is simply wrong: the scope
>> is by definition the Internet, so by definition locally inserted or
>> deleted extension headers are out of scope for this document. My
>> extra words are only intended to confirm that logic. If we don't
>> need them, so much the better.
> 
> We all know that the mission of the IETF is to “make the Internet
> work better” [rfc3935] – here is what I think is the relevant
> definition in this case (from Section 2. (Definition of Terms)): The
> Internet: A large, heterogeneous collection of interconnected systems
> that can be used for communication of many different types between
> any interested parties connected to it.  The term includes both the
> "core Internet" (ISP networks) and "edge Internet" (corporate and
> private networks, often connected via firewalls, NAT boxes,
> application layer gateways and similar devices).  The Internet is a
> truly global network, reaching into just about every country in the
> world. The IETF community wants the Internet to succeed because we 
> Starting from that definition, and please correct me if my
> interpretation is wrong, “expected to operate over the Internet”
> (from Fernando above) really points to the “core Internet”, right??
> 
> Yes, it is understood that the IETF works on protocols for “the
> Internet”, but “the Internet” really has two parts, one of them
> includes (among other things) what I’ve been calling a controlled
> domain (aka private network).
> 
> I’m then looking for a clarification on the applicability of
> rfc2460bis – something like (to paraphrase Brian): this document
> applies to packets intended to traverse the “core Internet”.
> 
>> => If someone comes up with a mechanism to safely do header
>> insertion and documents how to do it, that document can safely
>> progress. This can be done in a controlled domain as long as the
>> proponents are willing to address the concerns that have been
>> brought up and any breakage does not affect any unmodified nodes 
> For clarity, I would add that “safely progress” really means that
> 6man can consider it, and if adopted and consensus is reached, then
> it could be published.  I agree with that.
> 
> 
> Back to the original text of my DISCUSS.  By saying that “Without
> further clarifications and guidance, this document also brings on
> direction, or even the viability, of future work in the IETF.” … I
> meant that (without clarifying), it is very easy to assume that there
> are no exceptions to what is specified in rfc2560bis.   While it may
> be that everyone is in wild agreement about the applicability (to the
> “core Internet”) and whether others in the future can “safely
> progress” a different proposal, I want it documented so we don’t have
> to chase down old threads and argue about the intention of a
> document…
> 
> Thanks!
> 
> Alvaro.
>

---

From: "Stefano Previdi (sprevidi)" <[email-masked]>
Date: Tue, 11 Apr 2017 07:11:39 +0000

> On Apr 10, 2017, at 10:24 PM, Brian E Carpenter <[email-masked]> wrote:
> 
> is "insert, modify or delete”.

we don’t have a definition of “internet-wide” and we may well end up in another loop tying to agree what it means.

The simplest approach is to add an exception which consists of a controlled/closed domain (for which we do have a definition).

s.

---

From: Mark Smith <[email-masked]>
Date: Tue, 11 Apr 2017 22:02:27 +1000

> is "insert, modify or delete”.

we don’t have a definition of “internet-wide” and we may well end up in
another loop tying to agree what it means.

I think we do. In IPv6 devices that are given 2000::/3 addresses are part
of the IPv6 Internet.

Are you going to limit EH insertion to packets that only have ULA and
Link-Local addresses? How will that be policed to prevent people trying to
use EH insertion on packets with 2000::/3 addresses?

The simplest approach is to add an exception which consists of a
controlled/closed domain (for which we do have a definition).

Yet one that we know from RFC1918s and private network route leaks only
exist in theory.

The misuse of 1/8 as a private network demonstrates how "private" traffic
leaks outside closed domains that are attached to the Internet.

http://www.potaroo.net/studies/1slash8/1slash8.html

You spec could state that packets that have had EHs inserted MUST have them
removed, however in practice, they may not be removed because of
implementation bugs, device misconfiguration or partial device failure.

This failure to remove them will not be visible to the domain that added
them, because there are no local SR domain consequences of that failure.
Other receivers may suffer the consequences, yet there is nothing to
indicate in the packet which device or domain inserted the EH.

Consider this scenario, using an AS boundaries as a EH insertion domain
boundaries, with the packet travelling left to right, and this being a path
across the Internet. Imagine being at one of the ASes upstream of one or
both of the EH insertion ASes, trying to work out which one inserted the EH
and didn't remove it successfully.

[pkt src AS]--[AS1]--[EH INS ASX]--[AS2]--[EH INS ASY]--[AS3]--[AS4]--[pkt
dst AS]

To make this example more visceral, imagine [pkt src AS] is a residential
ISP who has with 10 of 000s of customers failing to access a streaming VoD
provider at [pkt dst AS]. Those angry customers will be ringing [pkt src
AS]'s helpdesk, increasing their support costs, market reputation and
possibly cost them customers, and [pkt dst AS] will be losing reputation,
revenue and possibly customers while this troubleshooting is going on.

Regards,
Mark.

s.

>>> The text already says that any node can examine the headers “for any
reason”, according to [rfc7045].  So maybe take that out as part of the
original 4.
>>>
>>> I do have an additional clarity question.  What does “process” mean?
Does it include a “change en-route”?    I’m asking because Section 4.2.
(Options) says that “the Hop-by-Hop Options header and the Destination
Options header” has an option bit that indicates “whether or not the Option
Data of that option can change en-route to the packet's final
destination”.  I’m assuming that to change the data the transit node has to
not just “examine” (which I think means “look at”), but also (at least)
“process” the EH as well.   If to “process” includes the ability to “change
en-route”, then it looks like the Destination Option may also be an
exception…
>>
>> I think most people always assumed process included inserting and
removing headers, but equally some people argue that strictly examining
involves some form of processing.
>> It’s tricky, without rewriting more text than was originally desired.
It would good for the text to be explicit, and non-contradictory.
>>> One way to improve the RFC7045 “contradiction” in the 2460-bis text
would be to rearrange the text to lift out the RFC7045 reference such that
it follows the text about the HbH option header, adding an example of
inspecting the payload, which is the main rationale for such inspection
stated in RFC7045.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 12 Apr 2017 01:39:03 +1200

> The simplest approach is to add an exception which consists of a controlled/closed domain (for which we do have a definition).

Unfortunately, we don't, as I discovered when I proposed such an
approach to allow local use of the IPv6 Flow Label. "Internet-wide"
on the other hand seems completely clear to me. Any node to any node.

    Brian

---

From: Fernando Gont <[email-masked]>
Date: Tue, 11 Apr 2017 16:33:52 +0100

> on the other hand seems completely clear to me. Any node to any node.

My understanding is that the "controlled domains" that R people talk
about is a different thing: they talk about controlled domains regarding
who inserts/removes EHs, rather than src/dst addresses of th packets.

If packets still have internet-wide srd/dst addresses, then packets
require internet-wide interoperability.

P.S.: This is a side comment -- as noted before, I'm against
"applicability statements" on rfc2460 for a bunch of reasons.

Thanks,

---

From: Stefano Salsano <[email-masked]>
Date: Tue, 11 Apr 2017 18:29:28 +0200

Il 2017-04-11 14:02, Mark Smith ha scritto:
> You spec could state that packets that have had EHs inserted MUST have
> them removed, however in practice, they may not be removed because of
> boundaries, with the packet travelling left to right, and this being a
> path across the Internet. Imagine being at one of the ASes upstream of
> one or both of the EH insertion ASes, trying to work out which one
> inserted the EH and didn't remove it successfully.
>
> [pkt src AS]--[AS1]--[EH INS ASX]--[AS2]--[EH INS
> ASY]--[AS3]--[AS4]--[pkt dst AS]
>
> To make this example more visceral, imagine [pkt src AS] is a
> residential ISP who has with 10 of 000s of customers failing to access a
> streaming VoD provider at [pkt dst AS]. Those angry customers will be
> ringing [pkt src AS]'s helpdesk, increasing their support costs, market
> reputation and possibly cost them customers, and [pkt dst AS] will be
> losing reputation, revenue and possibly customers while this
> troubleshooting is going on.

Dear Mark,

I want to clarify that the example you provided does not apply to the 
"controlled domain" insertion discussed in 
draft-voyer-6man-extension-header-insertion

according to draft-voyer-6man-extension-header-insertion,
ASX and ASY of your example are NOT allowed to insert EH in the packet 
originated by src AS

the EH is inserted in a outer packet which encapsulates the original one 
and with with a destination IPv6 address within the "controlled domain"

if you want to map your example into something that is aligned with 
draft-voyer-6man-extension-header-insertion, it should become something 
like the following (covering only EH insertion on ASX):

[pkt src AS]--[AS1]--[ASX:encapsulation of the packet in a new outer 
packet] [ASX:EH INS on the outer packet ]--[ASX:decapsulation of the 
packet]-- [AS2]-- [....] -- [pkt dst AS]

regards,
Stefano

>     >>> On 10 Apr 2017, at 14:53, Alvaro Retana (aretana)
>     <[email-masked] <mailto:[email-masked]>> wrote:
>     >>>
>     >>> Tim:
>     >>>
>     >>> Hi!
>     >>>
>     >>> The text already says that any node can examine the headers “for
>     any reason”, according to [rfc7045].  So maybe take that out as part
>     of the original 4.
>     >>>
>     >>> I do have an additional clarity question.  What does “process”
>     mean?  Does it include a “change en-route”?    I’m asking because
>     Section 4.2. (Options) says that “the Hop-by-Hop Options header and
>     the Destination Options header” has an option bit that indicates
>     “whether or not the Option Data of that option can change en-route
>     to the packet's final destination”.  I’m assuming that to change the
>     data the transit node has to not just “examine” (which I think means
>     “look at”), but also (at least) “process” the EH as well.   If to
>     “process” includes the ability to “change en-route”, then it looks
>     like the Destination Option may also be an exception…
>     >>
>     removing headers, but equally some people argue that strictly
>     examining involves some form of processing.
>     >>
>     >> It’s tricky, without rewriting more text than was originally
>     desired.  It would good for the text to be explicit, and
>     non-contradictory.
>     >>
>     >> Tim
>     >>
>     >>>
>     >>> Thanks!
>     >>>
>     >>> Alvaro.
>     >>>
>     >>>
>     >>>
>     >>>
>     >>> On 4/10/17, 4:52 AM, "Tim Chown" <[email-masked]
>     <mailto:[email-masked]>> wrote:
>     >>>
>     >>> Hi,
>     >>>
>     >>>> On 10 Apr 2017, at 04:03, Suresh Krishnan
>     <[email-masked] <mailto:[email-masked]>>
>     wrote:
>     >>>>
>     >>>> Hi Alvaro,
>     >>>>> On Apr 7, 2017, at 2:39 PM, Alvaro Retana <[email-masked]
>     <mailto:[email-masked]>> wrote:
>     >>>>>
>     >>>>> ==========
>     >>>>>
>     >>> One way to improve the RFC7045 “contradiction” in the 2460-bis
>     text would be to rearrange the text to lift out the RFC7045
>     reference such that it follows the text about the HbH option header,
>     adding an example of inspecting the payload, which is the main
>     rationale for such inspection stated in RFC7045.
>     >>>
>     >>> Old:
>     >>>
>     >> [email-masked] <mailto:[email-masked]>
>     >> Administrative Requests:
>     https://www.ietf.org/mailman/listinfo/ipv6
>     <https://www.ietf.org/mailman/listinfo/ipv6>
>     > [email-masked] <mailto:[email-masked]>
>     > Administrative Requests:
>     https://www.ietf.org/mailman/listinfo/ipv6
>     <https://www.ietf.org/mailman/listinfo/ipv6>
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/ipv6>

-- 
*******************************************************************
Stefano Salsano
Professore Associato
Dipartimento Ingegneria Elettronica
Universita' di Roma Tor Vergata
Viale Politecnico, 1 - 00133 Roma - ITALY

http://netgroup.uniroma2.it/Stefano_Salsano/

E-mail  : [email-masked]
Cell.   : +39 320 4307310
Office  : (Tel.) +39 06 72597770 (Fax.) +39 06 72597435
*******************************************************************

---

From: "Stefano Previdi (sprevidi)" <[email-masked]>
Date: Tue, 11 Apr 2017 19:30:39 +0000

> On Apr 11, 2017, at 5:33 PM, Fernando Gont <[email-masked]> wrote:
> 

as described in draft-voyer-6man-extension-header-insertion, the controlled domain is the domain where the packet is sourced _and_ (please, note the “and”) destined.

IOW, both SA and DA belong to the domain under the same control and within that domain all boxes that the packet will traverse are also under the same control.

draft-voyer-6man-extension-header-insertion also gives a couple of examples.

s.

---

From: [email-masked]
Date: Tue, 11 Apr 2017 23:11:51 +0200

> is "insert, modify or delete".

2460 doesn't (largely nor does the IETF) specify middlebox behaviour.
I am opposed to accommodating middleboxes in 2460.

The point of this text as I read it, is to specify what 2460 routers need to do. And the requirement for IPv6 forwarding is to only process the IPv6 base header (with one exception (HBH)).

Cheers,
Ole

---

From: [email-masked]
Date: Tue, 11 Apr 2017 23:17:43 +0200

Alvaro,

> I do have an additional clarity question.  What does “process” mean?  Does it include a “change en-route”?    I’m asking because Section 4.2. (Options) says that “the Hop-by-Hop Options header and…

Both options inside of an HBH option header and a Destination Options header can have the change en-route flag set.
The Destinations Options header are only processed at the destination host, so an option can then only change en-route when it is part of a source route path (and the Destination options header is before the routing header).

The "feature" here is that one can specify options that can be processed only by the routers listed in a routing header or one can specify options that can change en-route for every hop along the path.

Cheers,
Ole

---

From: Mark Smith <[email-masked]>
Date: Wed, 12 Apr 2017 07:30:48 +1000

> draft-voyer-6man-extension-header-insertion

I'm not talking specifically about
draft-voyer-6man-extension-header-insertion. This is a general example
of what could happen if packets that have inserted EHs leak outside
the notional controlled domain (it also serves as a more general
example of the problems of any operation that makes flight structural
modifications to packets that aren't attributable to the device that
makes them).

> the EH is inserted in a outer packet which encapsulates the original one and
> with with a destination IPv6 address within the "controlled domain"
>

They can still leak, c.f. RFC1918s.

In draft-voyer-6man-extension-header-insertion why have two methods
that achieve exactly the same outcome, with the only selection
criteria for the method being whether the traffic is originated
externally or internally?

Pick one that can serve both purposes that is most similar to existing
mechanisms, leverages existing deployed devices if possible, is the
one that will cause the least damage if it fails and is the easier and
quickest of the two to troubleshoot.

> draft-voyer-6man-extension-header-insertion, it should become something like
> the following (covering only EH insertion on ASX):
>
> [pkt src AS]--[AS1]--[ASX:encapsulation of the packet in a new outer packet]
> [ASX:EH INS on the outer packet ]--[ASX:decapsulation of the packet]--
> [AS2]-- [....] -- [pkt dst AS]
>

That's the model that I think should be used for all cases i.e. both
internal and externally originated traffic.

Regards,
Mark.

---

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Tue, 11 Apr 2017 21:33:30 +0000

Ole:

Hi!

Thanks for the clarification!  It would be nice if the document also said this – from what I could read, the text doesn’t match what you said – or did I miss it?

Alvaro.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 12 Apr 2017 14:33:36 +1200

Ole,
> The point of this text as I read it, is to specify what 2460 routers need to do. And the requirement for IPv6 forwarding is to only process the IPv6 base header (with one exception (HBH)).

I completely agree with that last sentence, but where does 2460bis state that
this is the scope of the document? 

    Brian

---

From: "Stefano Previdi (sprevidi)" <[email-masked]>
Date: Wed, 12 Apr 2017 05:35:09 +0000

> On Apr 11, 2017, at 11:30 PM, Mark Smith <[email-masked]> wrote:
> 
> the notional controlled domain

this does NOT happens for the simple reason that both SA and DA are within the domain. IOW, a packet reaches its destination within the domain, not outside.

s.

> (it also serves as a more general

---

From: Bob Hinden <[email-masked]>
Date: Wed, 12 Apr 2017 14:45:16 -0700

Alvaro,

> On Apr 11, 2017, at 2:33 PM, Alvaro Retana (aretana) <[email-masked]> wrote:
> 
> Ole:
> 
> Hi!
> 

On page 10:

   The third-highest-order bit of the Option Type specifies whether or
   not the Option Data of that option can change en-route to the
   packet's final destination.  When an Authentication header is present
   in the packet, for any option whose data may change en-route, its
   entire Option Data field must be treated as zero-valued octets when
   computing or verifying the packet's authenticating value.

      0 - Option Data does not change en-route

      1 - Option Data may change en-route

Was that your question?

Bob

---

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Wed, 12 Apr 2017 21:49:02 +0000

Bob:

Hi!

No, that was not my question.

Ole mentioned that “The Destinations Options header are only processed at the destination host, so an option can then only change en-route when it is part of a source route path (and the Destination options header is before the routing header).”  That “feature” (as Ole called it) is not part of the text.

Alvaro.

On 4/12/17, 5:45 PM, "Bob Hinden" <[email-masked]> wrote:

Alvaro,

On page 10:

Was that your question?

Bob

---

From: Bob Hinden <[email-masked]>
Date: Wed, 12 Apr 2017 15:03:25 -0700

Alvaro,

> On Apr 12, 2017, at 2:49 PM, Alvaro Retana (aretana) <[email-masked]> wrote:
> 
> Bob:
> 
> Hi!
> 

OK :-)

> Ole mentioned that “The Destinations Options header are only processed at the destination host, so an option can then only change en-route when it is part of a source route path (and the Destinatio…

That can be inferred by how destination extension headers are defined.  That is. they are processed at the destination indicated by the IPv6 destination address in the packet header.  From Page 9:

      note 1: for options to be processed by the first destination that
              appears in the IPv6 Destination Address field plus
              subsequent destinations listed in the Routing header.

Where Note 1, is for the Destination Options header on the previous page:

  Destination Options header (note 1)

Options in the hop-by-hop header are, of course, processed at every hop.

Bob

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 13 Apr 2017 13:31:36 +1200

I'm still not sure it's explaine completely by Bob's reply:

>               subsequent destinations listed in the Routing header.

In other words, if the packet is sent initially from S to D1, D1 may
process the destination options. If a routing header, also processed
by D1, flips the destination to D2, the destination options may be
processed by D2, and so on to the final destination Dn. However, other
routers on the path S--D1--D2----Dn do not process the destination options,
only HbH options.

That is indeed implied (but not explained in detail) by RFC2460 and RFC2460bis.

   Brian