Subject: RFC2460bis - Ticket #9 - Header injection issue

From: "Shwetha Bhandari (shwethab)" <[email-masked]>
Date: Wed, 1 Jun 2016 16:26:57 +0000

In view of the last call and the text added to 2460bis following the
discussion on the thread "Adding headers and adding options to headers²..

We have been experimenting with HbyH header injection and removal for the
purpose of collecting measurements relating to packet telemetry and we
have a working implementation of the same in VPP
[https://gerrit.fd.io/r/#/admin/projects/vpp] software data plane. We are
testing and will be publishing results of this experiments in due course.

While I am not proposing to add text to allow insertion and removal of
header in 2460bis, I most definitely do not want new text -

"Extension headers must never be inserted by any node other than the
source of the packet.  IP Encapsulation must be used to meet any
requirement for inserting headers, for example, as defined in   [RFC2473
<https://tools.ietf.org/html/rfc2473>].²

banning it completely.

I propose to continue having the text on extension header processing from
2460 as is without the new addition, as we do not have enough
evidence/data on this ambiguity leading to interop issues and that being
alleviated by addition of the above text.

Thanks,
Shwetha

---

From: "Frank Brockners (fbrockne)" <[email-masked]>
Date: Wed, 1 Jun 2016 16:32:58 +0000

+1

Agree that there are efforts (segment routing is another one) which experiment with in-flight insertion/removal of EH, and those efforts have running code available.
IMHO it  would be way too early to decide banning that capability. Let's keep the text in 2460 as is for now.

Regards, Frank

-----Original Message-----
From: ipv6 [mailto:[email-masked]] On Behalf Of Shwetha Bhandari (shwethab)
Sent: Wednesday, June 01, 2016 6:27 PM
To: 6man WG <[email-masked]>
Subject: RFC2460bis - Ticket #9 - Header injection issue 

In view of the last call and the text added to 2460bis following the discussion on the thread "Adding headers and adding options to headers²..

We have been experimenting with HbyH header injection and removal for the purpose of collecting measurements relating to packet telemetry and we have a working implementation of the same in VPP [https://gerrit.fd.io/r/#/admin/projects/vpp] software data plane. We are testing and will be publishing results of this experiments in due course.

While I am not proposing to add text to allow insertion and removal of header in 2460bis, I most definitely do not want new text -

"Extension headers must never be inserted by any node other than the source of the packet.  IP Encapsulation must be used to meet any
requirement for inserting headers, for example, as defined in   [RFC2473
<https://tools.ietf.org/html/rfc2473>].²

banning it completely.

I propose to continue having the text on extension header processing from
2460 as is without the new addition, as we do not have enough evidence/data on this ambiguity leading to interop issues and that being alleviated by addition of the above text.

Thanks,
Shwetha 

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

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 2 Jun 2016 08:47:49 +1200

Hi,

The reason for that text (which I and others assert is a clarifcation
of the intent of RFC 2460 and its predecessor RFC 1883) is to make
it clear that such insertions are not OK. The reasons that they are
not OK have been discussed here several times. The fact that such
insertions and deletions can be made to work inside a closed domain
doesn't make them OK for general use on the Internet.

Regards
   Brian Carpenter

---

From: Tim Chown <[email-masked]>
Date: Wed, 1 Jun 2016 20:55:11 +0000

Hi,

> On 1 Jun 2016, at 21:47, Brian E Carpenter <[email-masked]> wrote:
> 
> Hi,
> 

Indeed. And there are many more examples where the same applies.

Tim

---

From: Mark Smith <[email-masked]>
Date: Thu, 2 Jun 2016 10:15:33 +1000

> Indeed. And there are many more examples where the same applies.

I would also be expecting an update to the definition of the source address
field if this was to go ahead.

Regards,
Mark.

> >> Agree that there are efforts (segment routing is another one) which
experiment with in-flight insertion/removal of EH, and those efforts have
running code available.
> >> IMHO it  would be way too early to decide banning that capability.
Let's keep the text in 2460 as is for now.
> >>
> >> We have been experimenting with HbyH header injection and removal for
the purpose of collecting measurements relating to packet telemetry and we
have a working implementation of the same in VPP [
https://gerrit.fd.io/r/#/admin/projects/vpp] software data plane. We are
testing and will be publishing results of this experiments in due course.

---

From: 神明達哉 <[email-masked]>
Date: Wed, 1 Jun 2016 17:19:56 -0700

At Thu, 2 Jun 2016 08:47:49 +1200,

> doesn't make them OK for general use on the Internet.

+1.

I've stated my points on this several times, so I won't repeat them in
detail, but the "rationale" for leaving it unclear referring to
"interop issues" simply doesn't make sense to me.  I'm happy to hear
the discussion on revisiting the original intent as an update to
rfc2460bis, but for the scope of rfc2460bis itself clarifying it is
the right thing to do.

--
JINMEI, Tatuya

---

From: "Frank Brockners (fbrockne)" <[email-masked]>
Date: Thu, 2 Jun 2016 08:00:46 +0000

Hi,

So far I understood RFC2460 as a protocol spec - not an exclusive deployment guideline for the "big I" Internet. If a protocol behavior can be leveraged by a specific domain, why would we need to ban it completely by a clause like what is currently proposed ("Extension headers must never be inserted by any node other than the source of the packet"  - let along what the definition of "source" is) - which would apply to any use of the protocol, be it in specific domains or the global Internet. If we start to ban domain specific protocols or protocol aspects, I wonder what domain specific protocol we ban next. 

Could we rather consider adding a deployment guideline to 2460bis for use of EH on the global Internet (where the afore mentioned concerns apply)?

Thanks, Frank 

-----Original Message-----
From: Brian E Carpenter [mailto:[email-masked]] 
Sent: Wednesday, June 01, 2016 10:48 PM
To: Frank Brockners (fbrockne) <[email-masked]>; Shwetha Bhandari (shwethab) <[email-masked]>; 6man WG <[email-masked]>
Subject: Re: RFC2460bis - Ticket #9 - Header injection issue

Hi,

The reason for that text (which I and others assert is a clarifcation of the intent of RFC 2460 and its predecessor RFC 1883) is to make it clear that such insertions are not OK. The reasons that they are not OK have been discussed here several times. The fact that such insertions and deletions can be made to work inside a closed domain doesn't make them OK for general use on the Internet.

Regards
   Brian Carpenter

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 2 Jun 2016 08:02:01 +0000

Agreed,

At the moment, useful text would indicate what the perceived hazards are, and maybe provide BCP recommendations to ensure, say, traceability.
Once we get return from experience from the existing deployments, eg RPL or segment routing, we may fine tune those recommendations.

Cheers,

Pascal

> Sent: mercredi 1 juin 2016 18:27
> In view of the last call and the text added to 2460bis following the discussion on
> the thread "Adding headers and adding options to headers²..
> 
> purpose of collecting measurements relating to packet telemetry and we have a
> working implementation of the same in VPP
> While I am not proposing to add text to allow insertion and removal of header in
> 2460bis, I most definitely do not want new text -
> 
> "Extension headers must never be inserted by any node other than the source of
> the packet.  IP Encapsulation must be used to meet any
> 2460 as is without the new addition, as we do not have enough evidence/data
> on this ambiguity leading to interop issues and that being alleviated by addition
> of the above text.
> 
> Thanks,
> Shwetha
> 
>

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Thu, 2 Jun 2016 10:54:41 +0000

Having a deployment guideline seems reasonable, given that the protocols get used beyond public Internet. 

Perhaps, makes a distinction between public Internet and closed networks such as govt/classified networks.   

Cheers,
Rajiv 

> On Jun 2, 2016, at 4:01 AM, Frank Brockners (fbrockne) <[email-masked]> wrote:
> 
> Hi,
>

---

From: Ralph Droms <[email-masked]>
Date: Thu, 2 Jun 2016 07:06:33 -0400

> On Jun 1, 2016, at 4:47 PM 6/1/16, Brian E Carpenter <[email-masked]> wrote:
> 
> Hi,
> 

The IETF has strenuously (and, from personal experience, painfully) argued with other SDOs against similar extensions to IETF protocols to be used only inside a loser domain.  For example, look at Q.flowstatesig, which specified headers to be inserted into a TCP stream in an ingress router for a "bounded sub-network of an NGN" and deleted at the corresponding egress router.  The IETF took the position that such sub-domains cannot be enforced and leakage of the modified TCP stream would cause protocol breakage in hosts.

- Ralph

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 3 Jun 2016 08:41:29 +1200

The primary job of the IETF is to "make the Internet work better" (RFC3935).
In that context, I think that our *primary* standard for the future (RFC2460bis)
must provide global interoperability across any random path on the
Internet as an absolute requirement.

We can't stop people deploying non-interoperable variations within closed
domains, but see Ralph's message.

Regards
   Brian

On 02/06/2016 22:54, Rajiv Asati (rajiva) wrote:
> .

---

From: "Stefano Previdi (sprevidi)" <[email-masked]>
Date: Fri, 3 Jun 2016 07:20:04 +0000

I fully agree.

s.

> On Jun 1, 2016, at 6:26 PM, Shwetha Bhandari (shwethab) <[email-masked]> wrote:
>

---

From: Fernando Gont <[email-masked]>
Date: Tue, 7 Jun 2016 21:54:47 +0200

+1

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

---

From: Bob Hinden <[email-masked]>
Date: Sat, 18 Jun 2016 16:51:35 -0500

Hi,

Stefano, Brian, Ole and I have been discussion the “header injection” issue off list and have some text to propose.  The text in -04 is:

   Extension headers must never be inserted by any node other than the
   source of the packet.  IP Encapsulation must be used to meet any
   requirement for inserting headers, for example, as defined in
   [RFC2473].

The proposed new text is:

   The insertion of Extension Headers by any node other than the source
   of the packet breaks PMTU-discovery and can result in ICMP error
   messages being sent to the source of the packet that did not insert
   the header.

   One approach to allowing a header to be inserted is to encapsulate
   the packet using another IPv6 header and including the additional
   extension header after the first IPv6 header, for example, as defined
   in [RFC2473].

We think this better describes the issue, and then describes one approach to how to insert headers without breaking PMTUD.

I think this represents a good compromise from both sides of the discussion.

Comments please.

Thanks,
Bob

---

From: Mark Smith <[email-masked]>
Date: Sun, 19 Jun 2016 12:21:54 +1000

Hi,

On 19 Jun 2016 07:51, "Bob Hinden" <[email-masked]> wrote:
>
> Hi,
>
> Stefano, Brian, Ole and I have been discussion the “header injection”
issue off list and have some text to propose.  The text in -04 is:
>    of the packet breaks PMTU-discovery

It breaks anything that believes the source address reported in the packet
is the originator of the packet, which includes more than PMTUD.

PMTUD is one of the obvious cases where this causes problems. There could
be others, has complete analysis been done? Where is it? I think the
approach to slip in this exception to RFC2460bis might indicate it hasn't
been done.

This is a fundamental change to the semantics of the source address field.
Currently, the source address field describes the device that created the
entire structure of the packet and set the immutable values, and in many
cases, most or all of the mutable field values.

Allowing EH headers to be inserted means the source address may now not
describe the originator of the entire packet's structure and most if not
all of its field values. Most importantly, there is no way to tell if the
source address still has its RFC2460 meaning - there is no indication the
packet has been modified in flight.

Any packets that travel though an EH insertion domain may or will become
multi-source packets, because multiple layer 3 devices could be the sources
of parts if the packet. Multicast addresses are not allowed as source
addresses, nor should a single unicast address be allowed in the source
address field when the packet has multiple sources for its structure and
contents.

So the definition of the source address field needs to be changed, because
allowing in-flight packet insertions makes its definition wrong too.

In all this discussion I have not seen an explanation as to why EH
insertion is the best way to solve the particular problem. We are being
expected to accept that it is, and to then allow updates to RFC2460 to
allow it, despite knowing it causes problems.

(I suspect it is because of the tunnelling overhead, but that is my
thought, not those of the people wanting to insert EHs. If that is the
case, I proposed some ideas in draft-smith-enhance-vne-with-ipv6 which can
simply reduce IPv6 tunnelling overhead. If the real problem is tunnelling
overhead, then the solution that doesn't require making changes to
RFC2460bis is to work on methods of reducing IPv6 over IPv6 tunnelling
overhead.)

Standards are not set in stone, I think the barrier to change them is just
higher.

In this case, if people want to allow EH insertion, I think the process to
follow, which I would accept, is to prohibit EH insertion in RFC2460bis,
because it is such a fundamental change.

Then the EH insertion people need to write up a RFC that explains why EH
insertion is the better approach over tunnelling (and/or any other reasons
they've taken that approach), identifies all the issues that it will cause
to anything that currently believes the current definition of the source
address field, describes either how those issues will not cause fatal
errors or describes why and when these fatal errors are able to be
overcome. That RFC can then update RFC2460bis (after it is an RFC), which
would include updating the definition of the source address field to
describe what it actually now represents (something like "first creator of
some or all of the contents of the packet at the point in time along the
forwarding path or at the final destination the source address is
processed")

Regards,
Mark.

P.S., An analogy I've been using to remember and realise how significant
this change is is thinking about the sender field on letters I receive in
the (physical) post. I believe (and know it is illegal in .au) for the
postal system to modify the contents of letters and postcards, so I can
always attribute the contents to the reported sender. If the postal system
was allowed to modify contents without attribution,  I can never attribute
any of the contents entirety or possibly at all to the reported sender.
Legal prohibition of in flight modifications, backing the statement that
they say they won't do it, means I don't have to pay the price of
encryption and authentication of all of my letter contents.

> and can result in ICMP error
> We think this better describes the issue, and then describes one approach
to how to insert headers without breaking PMTUD.

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 19 Jun 2016 15:57:20 +1200

Mark,

But are you in a 'no objection' state for the proposed text?

Getting 2460bis published is the primary goal here. After that, we can discuss next steps.

Regards
   Brian

---

From: Mark Smith <[email-masked]>
Date: Sun, 19 Jun 2016 14:54:48 +1000

Hi,

> But are you in a 'no objection' state for the proposed text?

For ref:

"One approach to allowing a header to be inserted is to encapsulate
the packet using another IPv6 header and including the additional
extension header after the first IPv6 header, for example, as defined
in [RFC2473]."

I think the terminology "one approach" is not definitive enough.

I'm not against other methods that might be developed to insert EHs,
however I think they at a minimum they should not break deployed
existing mechanisms and existing field semantics, which inserting EHs
into an existing packet does.

I'd prefer text something like:

"The recommended approach to allowing a header to be inserted is to encapsulate
the packet using another IPv6 header and including the additional
extension header after the first IPv6 header, for example, as defined
in [RFC2473].

Alternate methods to add EHs to an existing packets may developed in
the future. They are expected to successfully interoperate with
existing IPv6 methods and mechanisms, and to preserve the semantic
meanings of this specification's IPv6 packet fields and field values."

Regards,
Mark.

> Getting 2460bis published is the primary goal here.

> After that, we can discuss next steps.
>
> Regards
>    Brian
>
>

---

From: Fernando Gont <[email-masked]>
Date: Sun, 19 Jun 2016 13:58:24 +0200

> I think this represents a good compromise from both sides of the discussion.

IMO, the reason for including the original text you quote above was to
remove the ambiguity in the text. The new text fails to respond the
question: is header insertion allowed?

Thanks,

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 20 Jun 2016 08:04:34 +1200

Hi Fernando,
> question: is header insertion allowed?

You're correct. RFC 2460 and RFC 1883 were ambiguous on this point too.
The suggested compromise leaves it ambiguous.

According to Merriam-Webster on-line, the first meaning of "compromise" is
"a way of reaching agreement in which each person or group gives up something
that was wanted in order to end an argument or dispute"

    Brian

---

From: Fernando Gont <[email-masked]>
Date: Mon, 20 Jun 2016 00:28:39 +0200

> that was wanted in order to end an argument or dispute"

IMO, publish a spec that we agree and know beforehand that is ambiguos
is not a good thing. I don't mind if EH-insertion is allowed, or
explicitly forbidden. But leaving it unspecified is not a good thing.

Besides, the text notes that EH insertion breaks PMTUD... so not sure
how that is acceptable. And, if you encapsulate (as noted in the updated
text), you're not really allowing EH insertion -- you're simply
encapsulating (creating another layer of IPv6).

Cheers,

---

From: Mark Smith <[email-masked]>
Date: Mon, 20 Jun 2016 13:49:09 +1000

> encapsulating (creating another layer of IPv6).

True, however I think the same end-result is achieved - EH encoded
information added to an existing packet as it is forwarded through the
network - without confusing what is the original packet and what EH(s)
was/were added, and attributing the EH addition to the device with the
outer source IPv6 address, rather than creating ambiguity about
whether or not it was the packet origin host that created respective
EHs in the packet.

Another advantage is that the outer header destination IPv6 address
very clearly specifies which device the tunnel header EH(s) is
intended to be processed by, and it could be a unicast, anycast or
multicast destination address. Other forwarding devices remain
oblivious to the EHs, performing standard IPv6 forwarding to get the
packet to the EH target device.

The alternative is for devices that might be interested in the EH
inserted into the original packet to have to follow the EH chain of
every packet they forward, just to see if the EH they're interested in
might be there. That's going to be more work per packet than standard
destination IP address forwarding/matching for EH processing that
encapsulation + encap. hdr. EH requires.

Regards,
Mark.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 20 Jun 2016 07:35:22 +0000

Hello Fernando;

Why are you reopening the dispute?

You know it's an infinite loop and all you get is a delay in the publication.

Note the if that group finally work on the right ways of inserting headers, it will also have to fix. PMTUD. Which is a good idea on its own because the concept of a (golden?) path to a destination is just unrealistic anyway. The proposed text is useful just to point this out.

Both are out of scope for 2460bis. So is changing the rules by banning what is not banned today. The proposed text is fair to the original mandate.

Regards,

Pascal

> Le 20 juin 2016 à 00:49, Fernando Gont <[email-masked]> a écrit :
>

---

From: Mark Smith <[email-masked]>
Date: Mon, 20 Jun 2016 18:35:43 +1000

On 20 June 2016 at 17:35, Pascal Thubert (pthubert) <[email-masked]> wrote:
> Both are out of scope for 2460bis. So is changing the rules by banning what is not banned today.

This from text RFC2460 that banned doing it:

"With one exception, extension headers are not examined or processed
   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 one exception being the Hop-by-Hop options header that needs to be
the first EH if present.

It was also in RFC1883 as quoted.

Similar text was also in RFC1710, "Simple Internet Protocol Plus White
Paper", with SIPP being what became IPv6.

"Most SIPP option
   headers are not examined or processed by any router along a packet's
   delivery path until it arrives at its final destination.  This
   facilitates a major improvement in router performance for packets
   containing options. In IPv4 the presence of any options requires the
   router to examine all options."

 The proposed text is fair to the original mandate.

---

From: 神明達哉 <[email-masked]>
Date: Mon, 20 Jun 2016 11:15:29 -0700

At Mon, 20 Jun 2016 00:28:39 +0200,

> explicitly forbidden. But leaving it unspecified is not a good thing.

I agree with Fernando here.

In my understanding, while the RFC2460 text was certainly ambiguous and
some people actually interpreted it as it allowed EH-insertion (or
deletion for that matter), it's never been the intent of the original
authors or most of the wg members.  We also know there are
interoperability issues that can happen due to the insertion/deletion.

Also in my understanding, although we have some level of sense that we
might revisit the original intent so we can make it a bit more
flexible under some specific conditions, we don't know precisely in
which condition we can allow the insertion/deletion of EHs.

Given these situations, leaving the original text ambiguous can lead
to more careless attempts of allowing the insertion/deletion without
thinking about the implication.  The more we have such attempts and
deployments, the more it will be difficult to fix the harm they
cause.  That's the main reason why I believe we should remove the
ambiguity at this opportunity.

Now, I'm not sure what kind of compromise was considered necessary (to
me the "compromise" and the revised text somehow suddenly emerged -
maybe I missed some intermediate discussions and consensus?), but if
it's to address the concern that the previously proposed text:

   source of the packet.

could invalidate the currently developed attempts of allowing the
insertion/deletion of EHs, I believe the right compromise is to still
eliminate the ambiguity about the original intent but to note this may
be loosened in future developments.  Such a compromise could read like
this:

   In the original design of IPv6 extension headers at the time
   RFC2460, extension headers are not supposed to be inserted (or
   deleted for that matter) by any node other than the source of the
   packet.  [Related issues with the insertion/deletion such as PMTUD
   may be inserted here]  But some recently developed attempts have
   sought to loosen the restriction under some particular set of
   conditions.  A future update to the protocol may allow such
   flexible behavior.  But, until the conditions that allow it are
   figured out, it is prudent for newer protocols to assume the
   originally intended restrictions.

--
JINMEI, Tatuya

---

From: Mark Smith <[email-masked]>
Date: Tue, 21 Jun 2016 11:47:24 +1000

On 21 June 2016 at 04:15, 神明達哉 <[email-masked]> wrote:
> In my understanding, while the RFC2460 text was certainly ambiguous

I don't find the RFC2460 text ambiguous. I think

is clear.

I don't think it is possible to insert an EH into a packet without
looking at (examining) the existing EHs and moving (processing) the
existing EHs to insert the EH.

(I think the only way you could "insert" an EH into a packet without
examining or processing the existing EHs is to blindly write an EH
directly after the IPv6 fixed header, regardless of what already
exists there. Of course, what ever was in that position originally was
probably pretty important to the sending and receiving hosts.)

> and

<snip>

  Such a compromise could read like
>    originally intended restrictions.

I think this is pretty good text as an alternative or as a compliment
to what I suggested the other day.

I would suggest changing the last sentence to something like:

"However, until the conditions that allow it are determined, newer
protocols should assume the originally intended restrictions."

Regards,
Mark.

---

From: "Stefano Previdi (sprevidi)" <[email-masked]>
Date: Tue, 21 Jun 2016 08:27:11 +0000

> On Jun 21, 2016, at 3:47 AM, Mark Smith <[email-masked]> wrote:
> 

if you think that rfc2460 is clear and unambiguous, then I don’t see why we should try to amend it.

Anyway, without consensus on any new text, it’s the direction we’ll have to take.

s.

---

From: Mark Smith <[email-masked]>
Date: Tue, 21 Jun 2016 20:23:47 +1000

> if you think that rfc2460 is clear and unambiguous, then I don’t see why we should try to amend it.

I'm fine with what it says. Apparently it has been misunderstood, so
being more definitive can only make it clearer.

Regards,
Mark.

<snip>

---

From: "Stefano Previdi (sprevidi)" <[email-masked]>
Date: Tue, 21 Jun 2016 10:45:15 +0000

> On Jun 21, 2016, at 12:23 PM, Mark Smith <[email-masked]> wrote:
> 
> I'm fine with what it says.

met too and this is what has been already pointed out a little while ago (in Buenos Aires).

> Apparently it has been misunderstood, so

It’s _one_ of the two options:

1. you’re satisfied with current text of rfc2460. In such case, nothing needs to be changed.

2. you’re not satisfied with current text of rfc2460. I such case, you’d like to see the text amended/modified in rfc2460bis.

(1) does not require any discussion, any action, we can close the issue.
(2) requires consensus before proceeding with publication.

It appear that (2) is far from being in reach.

s.

---

From: Tim Chown <[email-masked]>
Date: Tue, 21 Jun 2016 14:14:30 +0000

Hi,

> On 21 Jun 2016, at 02:47, Mark Smith <[email-masked]> wrote:
> 

Well, if it were 100% clear, we wouldn’t be having this discussion.  But I do agree, personally.

> protocols should assume the originally intended restrictions.”

I think Jinmei’s comments are very good, and the spirit of his proposed text is also good. I would also support your suggestion Mark to adapt Bob’s proposal to say “The recommended approach” rather than “One approach”.  This would still leave the door open for another approach to be proven later (i.e. the open door is the compromise).

Tim

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 22 Jun 2016 08:14:22 +1200

On 22/06/2016 02:14, Tim Chown wrote:
> Well, if it were 100% clear, we wouldn’t be having this discussion.  

That is indeed the point. Inserting, deleting or changing are three forms
of 'processing' in my opinion, but it seems that some implementors don't think so.

> But I do agree, personally.

OK... suppose all of us here agree that 'no processing' means 'no insertion,
deleting or changing.' How do we ensure that all readers of 2460bis understand
this from the text?

   Brian

---

From: Tom Herbert <[email-masked]>
Date: Tue, 21 Jun 2016 14:42:15 -0700

> deleting or changing.' How do we ensure that all readers of 2460bis understand
But doesn't the 'no processing' text only apply to non-HBH EH? Could
someone infer that it is okay to modify or add HBH. Since HBH must be
first EH in the packet it seems possible to add or modify it without
'processing' any other EHs.

Tom

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 22 Jun 2016 10:14:46 +1200

> 'processing' any other EHs.

That's the 'one exception' discussed immediately afterwards in the
text.

    Brian

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Tue, 21 Jun 2016 22:51:49 +0000

> From: ipv6 [mailto:[email-masked]] On Behalf Of Brian E Carpenter

> deleting or changing.' How do we ensure that all readers of 2460bis

Instead of "processing," why not say "modifying," or maybe even "inspecting and modifying" (with the one exception specified already)?

We seem to go around and around on this, because of what "consenting adults" have been known to do, strictly within their own administrative domain. Do we need words to the effect? That seems to be the issue.

Bert

---

From: Fernando Gont <[email-masked]>
Date: Wed, 22 Jun 2016 14:33:02 +0200

> deleting or changing.' How do we ensure that all readers of 2460bis understand

This is exactly my point. We're publishing a bis document, that
hopefully we'll be there for ages. It'd be too bad to leave this
"ambiguity" in, particularly when we knew about it at the time the bis
document was being discussed.

Given I've filled an errata, maybe a good first step would be to make a
decision on the errata?

Thanks,

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Wed, 22 Jun 2016 13:09:52 +0000

> On Jun 22, 2016, at 8:33 AM, Fernando Gont <[email-masked]> wrote:
> 

The circular nature of this discussion is not helping, Fernando. The content of that errata has been the subject of this circular thread.

In my opinion, an errata is the wrong vehicle for this — and as 2460bis is being discussed, given all the emails on the topic thus far, the proposal at:

https://mailarchive.ietf.org/arch/msg/ipv6/BMvHuIY90p107-rPS6UVcig5y2k

is what gets us closer to the original 2460 and original discussion.

This would fork any potential subsequent discussion and consensus building for after 2460bis — and an I-D seems a better vehicle than further extending this thread ad nauseam and holding 2460bis.

Thanks,

— Carlos.

---

From: Fernando Gont <[email-masked]>
Date: Wed, 22 Jun 2016 15:27:39 +0200

On 06/22/2016 03:09 PM, Carlos Pignataro (cpignata) wrote:
>
>>> OK... suppose all of us here agree that 'no processing' means 'no
>>> insertion, deleting or changing.' How do we ensure that all
>>> readers of 2460bis understand this from the text?
>> 
>> "ambiguity" in, particularly when we knew about it at the time the
>> bis document was being discussed.
>> 
>> Given I've filled an errata, maybe a good first step would be to
>> make a decision on the errata?
>> 
> 
> The circular nature of this discussion is not helping, Fernando. The
> content of that errata has been the subject of this circular thread.
> 
> In my opinion, an errata is the wrong vehicle for this — and as
> 2460bis is being discussed, given all the emails on the topic thus
> far, the proposal at:
> 
> This would fork any potential subsequent discussion and consensus
> building for after 2460bis — and an I-D seems a better vehicle than
> further extending this thread ad nauseam and holding 2460bis.

Honestly, I don't see a circular discussion.

It all started with the question regarding whether EH insertion is
supposed to be allowed. Bob himself noted that "no", and a number of
people gave examples of the things that can go wrong when doing that. --
I think that for most, it was understood that it was not possible, but
given the recent discussion, a clarification was warranted.

But a group of folks still want to insert EHs.

When I look at the new text, the question about whether EH insertion is
allowed or not is not clear. And I think it should be. Either state that
it is allowed (which IMO would be a change, but you might think
otherwise), or clarify that it is not. But leaving this feeling of "not
sure if its possible" doesn't seem right.

Thanks,

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Wed, 22 Jun 2016 13:55:55 +0000

> On Jun 22, 2016, at 9:27 AM, Fernando Gont <[email-masked]> wrote:
> 

That happens if you are moving together with the discussion in circles :-)

> sure if its possible" doesn't seem right.

The safest route seems to be to describe and explain what’s known about the subject. The new proposed text at <https://mailarchive.ietf.org/arch/msg/ipv6/BMvHuIY90p107-rPS6UVcig5y2k> achieves just that. It lists potential results of EH insertion by any node. It also goes further and lists one approach that eliminates those results. (the text could also list PL-PMTUD) To me, this is a step forward without allergic reactions, that makes the gist of the discussion explicit.

Thanks,

— Carlos.

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Mon, 27 Jun 2016 18:15:17 +0000

> On Jun 21, 2016, at 3:51 PM, Manfredi, Albert E <[email-masked]> wrote:
> 

My understanding is that section 4.2 explicitly allows an option to be modified/changed/whatever-it's-called in flight if bit 2 (0,1,2 counting from MSB) is set. An example of such a use case would implement RCP or XCP; the option in the HBH header collects statistical information from the network, and the same option as a destination option returns the result to the sender, which then uses it in the evolution of the TCP/SCTP/QUIC/whatever Effective Window. So this discussion makes me uncomfortable.

We're discussing changing the size or existence of the header, or the set of objects it contains, not the contents of an existing object. Right?

---

From: Tom Herbert <[email-masked]>
Date: Mon, 27 Jun 2016 11:30:06 -0700

> We're discussing changing the size or existence of the header, or the set of objects it contains, not the contents of an existing object. Right?
I think it may raise another interesting question. Does changing a HBH
option include that it can be removed? And if we do allow to removing
HBH options would that then allow removing the HBH EH entirely? There
is a practical aspect to this in that a source network may have good
support for HBH options and they could be used productively within
that network, however when packets egress into the Internet we might
want to strip HBH options and EH to improve reachability of packets.

Tom

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Mon, 27 Jun 2016 18:53:22 +0000

> From: Tom Herbert [mailto:[email-masked]]

> want to strip HBH options and EH to improve reachability of packets.

Yes, exactly where I'm coming from too. Maybe it needs to be stipulated explicitly, that should any administrative domain's nodes (routers) decide to inject extension headers upon ingress, then they must restore the original header upon egress. So the destination thinks the only extension headers in the packet were those inserted by the source, including the HBH EH.

Somehow or other, it would be nice if any oddball use of EHs were kept localized to the "consenting adults."

Bert

---

From: Tom Herbert <[email-masked]>
Date: Mon, 27 Jun 2016 12:11:49 -0700

> Yes, exactly where I'm coming from too. Maybe it needs to be stipulated explicitly, that should any administrative domain's nodes (routers) decide to inject extension headers upon ingress, then the…
In the case I am considering it is still only the end host that
creates EH. This model would allow forward signaling from hosts to
local network nodes (maybe signal L4 state to a FW like being
contemplated in PLUS), but doesn't help with packet in the reverse
path unfortunately.

Tom

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 28 Jun 2016 08:15:04 +1200

Regards
   Brian Carpenter
   http://orcid.org/0000-0001-7924-6182

> want to strip HBH options and EH to improve reachability of packets.

Any of these things breaks IPsec AH, which has a specific exception for
value changes in options but not for length changes.

   Brian

---

From: Mark Smith <[email-masked]>
Date: Tue, 28 Jun 2016 13:41:03 +1000

> value changes in options but not for length changes.

I haven't seen an explanation as to why EH insertion and removal
within a domain, and its associated complexity, is better than
tunnelling with the added EH being part of the outer tunnel headers.

The more I think about using tunnelling for accommodating adding EHs
to pre-existing packets the more it makes sense to me.

The encapsulator gets to choose which device sees the added EH by
specifying the outer header (unicast, anycast or multicast)
destination address (making the packet destinations end-systems or
hosts in RFC2460 parlance). Devices that don't have that outer
destination address perform standard IPv6 forwarding, remaining
oblivious to the addition of the EH (via tunnelling) to the
pre-existing packet.

If the added EH happens to be a newly defined one, only the set of
devices that may be specified as destinations for these tunnel packets
need to be upgraded to understand the new EH. These upgraded devices
also remain oblivious to any added new EHs if they aren't assigned the
packet's outer IP address, meaning simplified and standard IPv6
forwarding for these packets, rather than having to inspect the EH
chain of each and every packet they receive for the presence of the
new EH.

Regards,
Mark.

N

---

From: Tom Herbert <[email-masked]>
Date: Wed, 29 Jun 2016 10:14:26 -0700

> tunnelling with the added EH being part of the outer tunnel headers.
I think it could be argued that tunneling incurs additional overhead,
complexity, and is not transparent which could be an undue burden.

For example, consider the mobile wireless case where we want
bi-directional signaling between the host and network to indicate
network-layer characteristics of the wireless link (something like a
generalization of draft-flinck-mobile-throughput-guidance-03.txt). If
we are able to use HBH options for this use case then host application
will be able to easily set HBH options on a socket for setting on the
sending path. The local network can consume this information and can
strip the options from the packets when they egress the network-- this
limits information exposure and avoids the possibility that some third
party device in the Internet drops the packet because of HBH. On
ingress into the network, a network device could insert EH for
consumption by the end host. The local network can be engineered so
that the enlarged packet will still fit into any MTU.

If we try to get the same effect with encapsulation, this requires
significant changes on the mobile client. Tunneling doesn't "just
work", it needs specific implementation and configuration. We would
need encapsulation/decapsulation enabled (probably kernel needs to be
involved) and selection of the destination address in the
encapsulation may be non-trivial, especially if we want the
destination to be the egress router corresponding to the best one for
the actual destination. Also, the forty bytes of overhead for the
additional IP header in every packet may be significant overhead in
some domains.

Tom

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Wed, 29 Jun 2016 17:36:17 +0000

> On Jun 27, 2016, at 11:41 PM, Mark Smith <[email-masked]> wrote:
> 

I think this is the wrong line of thinking within the context of RFC2460bis and this discussion.

It really is not about whether EH insertion is *better than* or *worst than* tunneling with the added EH. It is not a competition, and perhaps even naïve to assume there is a unique solution for every potential use case.

To me, the net-net of it is that the proposed text describes the issue and a current solution, without overreaching and overprescribing beyond 2460bis scope. — Although I’d prefer to s/The current approach/One approach/, I support that text.

Thanks,

— Carlos.

---

From: Mark Smith <[email-masked]>
Date: Thu, 30 Jun 2016 20:04:47 +1000

On 30 June 2016 at 03:36, Carlos Pignataro (cpignata)
<[email-masked]> wrote:
> It really is not about whether EH insertion is *better than* or *worst than* tunneling with the added EH. It is not a competition,

So I think broadly it actually is a competition, because ideally we
want a single solution that can facilitate all as many similar use
cases as possible, and ideally all of them, as well as one that
inter-operates with existing specifications and deployed
implementations. We want a single clear winner if we can find one, not
multiple candidate winners that don't differ that much.

To create a new solution to a problem that can probably be solved
using existing methods and mechanisms really means that the new
solution needs to provide some "compelling" advantage or benefit over
the existing method, that justifies and outweighs the newly created
costs of the new solution, such as new specifications, new code,
possible confusion about which solution to use when they're both
possible candidates, and conflict resolution methods or preferences if
they happen to be co-deployed. (This is why I've developed quite a
strong personal objection to DNS options in RAs - I don't think they
provide a compelling enough benefit over deploying stateless DHCP,
which can provide DNS as well as many other pretty essential host
parameters such as NTP.)

I haven't yet seen the "compelling" benefits of inserting EHs that
outweighs the corresponding incurred costs, in comparison to the
existing methods of adding them via tunnelling that co-exists with
existing mechanisms.

> and perhaps even naïve to assume there is a unique solution for every potential use case.
>

The thing I want to see the text do is encourage the use of the
existing tunnelling method that doesn't cause PMTUD and similar
issues, rather than being neutral about it. I think the 'The current
approach' does that.

Regards,
Mark.