Subject: Re: proposed text for header injection revision 05

From: "C. M. Heard" <[email-masked]>
Date: Thu, 21 Jul 2016 17:17:44 -0700

Hello everyone,

I will probably get splattered with dead cats and rotten tomatoes for
saying this, but if the only way that consensus can be achieved on 2460bis
is to leave it ambiguous, then it's just not ready to be an Internet
Standard. If I were on the IESG and a spec that came to me with a known
ambiguity, I would vote to send it back to the WG with instructions to
resubmit it after the ambiguity was fixed.

I think it's clear, if not actually obvious, that the original intent of
2460 was that no intermediate IPv6 node would change the length of an IP
datagram. If that's the correct technical approach, then let's say so
explicitly in 2460 bis, and then we can advance it to IS. If that's not the
correct technical approach, then let's change the rule and stay at PS.

Mike Heard

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 22 Jul 2016 19:08:46 +1200

> resubmit it after the ambiguity was fixed.

That is the risk in a compromise, of course. Perhaps we should ask for
guidance from the AD.

> datagram. 

I am certain of that, from the extract from meeting minutes that I cited
some weeks ago. And of course IPsec also limits what you can change.

    Brian

> If that's the correct technical approach, then let's say so
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Francis Dupont <[email-masked]>
Date: Fri, 22 Jul 2016 11:11:38 +0200

>  correct technical approach, then let's change the rule and stay at PS.

=> it was so header injection should be forbidden without any text
about other approach (i.e, KISS) and the whole stuff advance to IS
(as I asked at the mike some meetings ago).

Regards

[email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 22 Jul 2016 21:47:13 +1200

> (as I asked at the mike some meetings ago).

What I seem to have heard this week is that many people think that
the proposed compromise is ambiguous (which is true) and that
*therefore* it is not acceptable in an Internet Standard.

If that is the consensus, then it does seem to me that there is
no choice but to state the original (pre-RFC1888) intent that
with the exception of HbH, extension headers MUST NOT be modified,
inserted or deleted by forwarding nodes. In terms of the old
text, this is just s/processed/processed, modified, inserted or deleted/
in the appropriate sentence.

(To be clear, that doesn't affect the routing header because it
is only modified by the destination host, even though that isn't
the final destination of the packet.)

If we do that, we don't require either of the two new paragraphs,
but they remain valid if we want to keep them.

   Brian

---

From: Francis Dupont <[email-masked]>
Date: Fri, 22 Jul 2016 11:51:29 +0200

>  the final destination of the packet.)

=> I agree that clarifying the term "processed" is the simplest
solution so the best.

>  but they remain valid if we want to keep them.

=> IMHO we should have minimal normative text, i.e., remove not
normative text which doesn't really help (2nd paragraph) and
avoid redundant normative (so the first paragraph, of course
only if we can get a consensus about the "processed" clarification).

Thanks

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 22 Jul 2016 11:46:18 +0000

Hello Brian:

The word "processed" cannot be kept because many intermediate boxes read the EHs (and transport headers)  and act on them. It was indicated at the meeting that "reading" is a form of "processing". 

People will not unplug their middle boxes no will they stop adding them, whatever we write now in a spec.

We sometimes have discrepancy between the deployed world and the standards, e.g. with the HbH EH. The world judges the specs and makes what it can of them. It is good that in that particular occasion, this group listened to the world, and made the processing optional.

In a more general fashion, publishing a document that is not followed by the reality of the world does not help. It makes the document less relevant, I'm afraid. 

For IS level, I'd rather go for a document that is fully relevant, even if that means slightly ambiguous.

Cheers,

Pascal

> -----Original Message-----
> From: ipv6 [mailto:[email-masked]] On Behalf Of Brian E Carpenter
> Sent: vendredi 22 juillet 2016 11:47
> To: [email-masked]
> Subject: Re: proposed text for header injection revision 05
> 
> >>  2460 was that no intermediate IPv6 node would change the length of
> >> an IP  datagram. If that's the correct technical approach, then let's
> >> say so  explicitly in 2460 bis, and then we can advance it to IS. If
> >> that's not the  correct technical approach, then let's change the rule and stay
> at PS.
> >
> > about other approach (i.e, KISS) and the whole stuff advance to IS (as
> > I asked at the mike some meetings ago).
> 
> What I seem to have heard this week is that many people think that the
> proposed compromise is ambiguous (which is true) and that
> If that is the consensus, then it does seem to me that there is no choice but to
> state the original (pre-RFC1888) intent that with the exception of HbH, extension
> headers MUST NOT be modified, inserted or deleted by forwarding nodes. In
> terms of the old text, this is just s/processed/processed, modified, inserted or
> deleted/ in the appropriate sentence.
> 
> (To be clear, that doesn't affect the routing header because it is only modified
> by the destination host, even though that isn't the final destination of the
> packet.)
> 
> If we do that, we don't require either of the two new paragraphs, but they
> remain valid if we want to keep them.
> 
>    Brian
>

---

From: [email-masked]
Date: Fri, 22 Jul 2016 13:50:32 +0200

> *therefore* it is not acceptable in an Internet Standard.

I cannot in RFC2026 or RFC6410 find that lack ambiguity is a requirement to advance a document.

From RFC5218 you could imply that protocol design that allowed it to be used in ways outside of our wildest expectations, is what makes for successful protocols.

> but they remain valid if we want to keep them.

Reading through this thread... I'm not quite sure what the perceived ambiguity actually is.
Is it _just_ for the exception, i.e. the HBH header?

Cause I cannot see any ambiguity for the other headers:

   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.

(I don't know of a single router implementation or deployment that does not violate this though.
If we want to take deployment experience into account, it would make more sense to remove that paragraph than to strengthen it.)

Best regards,
Ole

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 23 Jul 2016 03:23:53 +1200

> The word "processed" cannot be kept because many intermediate boxes read the EHs (and transport headers)  and act on them. It was indicated at the meeting that "reading" is a form of "processing". 

"Processed" is unclear, but the actual old text is "examined or processed" which
is definitely violated by many middleboxes. The 2460bis text has dropped
"examined" which recognizes the reality of firewalls.

> People will not unplug their middle boxes no will they stop adding them, whatever we write now in a spec.

Correct.

> We sometimes have discrepancy between the deployed world and the standards, e.g. with the HbH EH. The world judges the specs and makes what it can of them. It is good that in that particular occasi…

We didn't. The current 2460bis text is just as vague about "processed" as 2460, in fact.

   Brian

> .

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 23 Jul 2016 03:36:24 +1200

> I cannot in RFC2026 or RFC6410 find that lack ambiguity is a requirement to advance a document.

That's probably true. But it's still a matter of community consensus;
it's above my pay grade to determine that.

>    identified in the Destination Address field of the IPv6 header.

Does "process" include insert, delete or modify? I say yes, others say no.

(Again, "examined" is already deleted in 2460bis.)

> If we want to take deployment experience into account, it would make more sense to remove that paragraph than to strengthen it.)

Well, we have experience or at least definite knowledge that inserting a header
breaks PMTUD. We also have experience that "processing" fragment headers by
dropping them breaks IPv6.

Sorry about this but I thought we had compromise wording. Now it seems we don't.

Regards
   Brian

---

From: Mark Smith <[email-masked]>
Date: Sat, 23 Jul 2016 12:10:47 +0930

> People will not unplug their middle boxes no will they stop adding them, whatever we write now in a spec.

Formally accommodating middle boxes is actually a formal statement
that the IETF don't think end-to-end encryption (more generally
Internet confidentiality) is necessary or useful.

---

From: Michael Richardson <[email-masked]>
Date: Sat, 23 Jul 2016 07:39:51 -0400

> (I don't know of a single router implementation or deployment that does

okay, they examined, and the result affects the processing of the packet,
but are they mutated by all router implementations?

    > If we want to take deployment experience into account, it would make
    > more sense to remove that paragraph than to strengthen it.)

I think that this is key: We need a document that reflects what really
happens out there, as this has material impact on what we can do in the
future.

(I think that the biggest argument for not mutilating packets in the middle
is because that's how we got NAT and SPUD/PLUS/etc.  I'd rather document
how to do safe, sane (and consensual[%]) changes to packets.)

[%]-https://en.wikipedia.org/wiki/Safe,_sane_and_consensual

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Michael Richardson <[email-masked]>
Date: Sat, 23 Jul 2016 07:41:10 -0400

> Sorry about this but I thought we had compromise wording. Now it seems

We got rather rough consensus around ambiguous language because that language
permitted everyone to interpret it their way.

---

From: "Stefano Previdi (sprevidi)" <[email-masked]>
Date: Mon, 25 Jul 2016 10:45:54 +0000

Brian, Ole,

[...]

> That's probably true. But it's still a matter of community consensus;

it looks to me we are stalled into a non-consensus situation and each time we try to reach some compromise we fall back into a long discussion (live or through emails).

The closer we got to a form of consensus was during the meeting after Mark’ suggestion to remove the second paragraph. However, the situation hanged since.

At this stage what are the options if consensus in not reached on a specific piece of text ?

Thanks
s.

---

From: Tim Chown <[email-masked]>
Date: Mon, 25 Jul 2016 12:27:31 +0000

Hi,

> On 23 Jul 2016, at 12:39, Michael Richardson <[email-masked]> wrote:
> 

I like the spirit of what Michael wrote above. Perhaps a way forward is by following this principle, for which I have a strawman short and long answer below. The snag is whether there is room in 2460bis to be pragmatic in this way.

In short:

1. We push RFC2460bis forward such that it simply states what we have widespread successful deployment of today (which is a requirement for Internet Standard anyway)

2. We document the (harmful) side-effects of EH insertion on path (preferably within 2460, or as a separate document that might be updated with experience later).

3. We agree that if in the future we identify cases where EH insertion can be done “safely and sanely” (for a value of “safely and sanely” tbd), then we will document these, as Experimental or Proposed Standards appropriately.

Such an approach would capture current practice in 2460, ensure understanding of consequences of EH insertion are known, and leave the door open for future innovation. Were that agreed, “all” we’d need to do is agree what each means in practice.

** 1. RFC2460bis reflecting current practice **

Current practice is that nodes on a path, i.e. routers, are expected to examine the HBH Options header, but we have already noted in 2460bis as it is that routers in high-performance scenarios may not actually have capacity to do this fully, or even partially.  So the new “where explicitly configured to do so” text seems in line with current practice, relaxing the previous requirement.

Many might say examining in this case is one form of processing, so just saying “processing” and removing “examining” seems reasonable too.

Current practice is also that intermediate nodes on a path might also process EHs in any situation where they might need to look past the EH chain into the transport headers or deeper, e.g. at an IDS/firewall, or a load balancer.  In that light, the current paragraph in 2460bis:

"With one exception, extension headers are not 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.  Note: If an
   intermediate forwarding node examines an extension header for any
   reason, it must do so in accordance with the provisions of [RFC7045]."

reads a little clumsily. It says the exception is only the HBH Options header, then implies you can do more, so long as you’re RFC7045 compliant. Not ideal.

I think Ole suggested we might consider dropping this paragraph altogether, but we can probably do better.  Perhaps something like:

“If an intermediate node needs to inspect transport headers or beyond,
  e.g. for security or load balancing purposes, it must examine all EHs
  in accordance with the provisions of [RFC7045]. Otherwise, except for
  handing of the HBH Option header as described below, EHs are not
  expected to be processed by nodes on 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."

So we would still be ducking the explicit calling out of what “process” means, but the use of “expected” is a little stronger than one we have now, and the presence of pragmatic EH processing cases as per RFC7045 is stated.

** 2. Document the side-effects of EH insertion on path **

Currently the “health warning" in 2460bis says:

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

We should add to this the comments from the list about IPSec AH (however little it may be used) and re-calculating checksums. It wouldn’t be hard to come up with some text.  I would certainly change “that did not insert the header” to “rather than the node that inserted the header.”  The text from RFC6554 is nice, which says "Use of tunnelling ensures that the datagram is delivered unmodified and that ICMP errors return to the source of the SRH rather than the source of the original datagram."

And of course we also have this contentious paragraph:

"The current 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 am fine with it being removed, BUT to get consensus we could ground it in a Proposed Standard example, e.g. we could say:

“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 for the RPL Type 3 Routing Header as described in
   Section 2 of [RFC6554].”

This also removes use of the word “current”, which would look silly in a few years time.

I would advocate this being in 2460bis rather than a separate document, but if the latter helps with consensus, and later updates with experience from whoever is inserting EHs, so be it.

** 3. Document header insertion use cases **

So the open question here, is what are those use cases?

It seems they are currently around scenarios where an IPv6 packet enters a domain where IPv6 Routing Headers are used, to allow that packet to be passed around that domain with RHs being used to “steer” the packet while it remains in that domain, from which it may or may not emerge.

The two cases I am aware of here are RPL and SPRING, which at least originally were targeted at single administrative domains.

For RPL, RFC6554 (defining the Type 3 RH) says in Section 2:

" 1. If the SRH specifies the complete path from source to
     destination, the router places the SRH directly in the datagram
     itself.

 2.  If the SRH only specifies a subset of the path from source to
     destination, the router uses IPv6-in-IPv6 tunneling [RFC2473] and
     places the SRH in the outer IPv6 header.  Use of tunneling
     ensures that the datagram is delivered unmodified and that ICMP
     errors return to the source of the SRH rather than the source of
     the original datagram."

So in this case it seems that encapsulation is used, not EH insertion. However, some implementations are apparently inserting (based on list comments) on the grounds of conserving battery and/or bandwidth, but that seems to not be to the spec.  Michael has documented RPL cases in draft-ietf-roll-useofrplinfo-07.

For SPRING, draft-ietf-6man-segment-routing-header-01 (defining the Type 4 RH) says in Section 5:

"The Segment Routing Header (SRH) is simply another type of the
   routing header as described in RFC 2460 [RFC2460] and is:

   o  inserted by an SR edge router when entering the segment routing
      domain or by the originating host itself.  The source host can
      even be outside the SR domain;

   o  inspected and acted upon when reaching the destination address of
      the IP header per RFC 2460 [RFC2460]."

So in this case “inserted” is ambiguous; it could mean true insertion, or encapsulation.

It seems we should look at these cases more closely, as I assume these are the cases that those objecting to EH insertion being explicitly outlawed in 2460bis are concerned about. Or are there other current use cases for EH insertion?  If so, are they described in IETF documents?

And then we try to ensure Michael’s "safe, sane and consensual changes” can be done in practice.

Tim

---

From: "C. M. Heard" <[email-masked]>
Date: Mon, 25 Jul 2016 08:52:13 -0700

On Thu, 21 Jul 2016 18:58:39 +0200, Fernando Gont wrote:
> Note, again: I don't care much about the outcome.

But we should care about the outcome. If an extension headers is
inserted by any node other than the source of the packet, any ICMP
error message related  to that header goes back to the original source
of the packet, not to the node that inserted the offending header.
If that's not a fatal technical flaw, I don't know what is.

Echoing Brian Carpenter, let's please go back to the version at
https://tools.ietf.org/html/draft-ietf-6man-rfc2460bis-01#page-7,
which unambiguously addresses the issue, reflects the original
intent of RFC 2460, and has no known technical omissions.

//cmh

---

From: [email-masked]
Date: Mon, 25 Jul 2016 20:10:01 +0200

Tim,

> I think Ole suggested we might consider dropping this paragraph altogether, but we can probably do better.  Perhaps something like:

My comment was intended to show that the argument used about "original intent" didn't necessarily matter much to the people implementing or deploying the protocol.

I do think it has value to clearly state that in the IPv6 architecture there are only hosts and routers. And that a correctly implemented and deployed IPv6 network does not examine nor process anything beyond the initial IPv6 header (minus the HBH header).

From an Internet architecture point of view I cannot see how we can say anything else.

I would be very reluctant to introduce any language in 2460bis allowing middleboxes.

Best regards,
Ole

---

From: [email-masked]
Date: Mon, 25 Jul 2016 20:18:51 +0200

Stefano,

> At this stage what are the options if consensus in not reached on a specific piece of text ?

That's a good question. If the working group would be willing to live with and respect the outcome, we could ask our AD to make a decision. Or we could leave this issue open and revisit it in Seoul, or we could give up on making 2460 Internet standard.

When Bob is back mid-August I'll initiate a discussion with our ADs and see if we can come up with any other ways forward.

As an observation; the text we are discussing is not protocol specification, it is protocol politics. And while I believe enshrining our values into protocols is fundamental to IETF work, - like routers not being allowed to  look beyond the IPv6 header, or the 64 bit boundary, it is always navigation in rocky waters.

Best regards,
Ole

---

From: Tim Chown <[email-masked]>
Date: Mon, 25 Jul 2016 18:29:33 +0000

Hi Ole,

> On 25 Jul 2016, at 19:10, [email-masked] wrote:
> 
> Tim,
> 

So it seems.

> I would be very reluctant to introduce any language in 2460bis allowing middle boxes.

I understand that, and that would be my preference too, but the current 2460bis introduces a “handle EHs as per RFC7045” sentence (which pragmatically is what we want to do), and as a reminder RFC7045 then says this on forwarding nodes:

"Any forwarding node along an IPv6 packet's path, which forwards the
   packet for any reason, SHOULD do so regardless of any extension
   headers that are present, as required by RFC 2460. Exceptionally, if
   a forwarding node is designed to examine extension headers for any
   reason, such as firewalling, it MUST recognise and deal appropriately
   with all standard IPv6 extension header types and SHOULD recognise
   and deal appropriately with experimental IPv6 extension header types.”

So the middlebox (firewall) behaviour is implicitly included in 2460bis already. Though in this case you could read it as firewalling based on EH contents, not transport headers or beyond, but you’d need to attempt to look through the whole chain up to the transport header regardless of whether that was then inspected too.

>> of multicast) identified in the Destination Address field of the IPv6 header.”

So one could rewrite this as:

"If an intermediate forwarding node is designed to examine extension
 headers for any reason, such as firewalling, it must do so in
 accordance with the provisions of [RFC7045]. Otherwise, except for
 handing of the HBH Option header as described below, EHs are not
 expected to be processed by nodes on 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.”

which is then using the same language as RFC7045. Delete “expected to be” if preferred. I think that ordering reads better.

Tim

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 26 Jul 2016 14:12:33 +1200

> As an observation; the text we are discussing is not protocol specification, it is protocol politics. And while I believe enshrining our values into protocols is fundamental to IETF work, - like ro…

It is. However, I think we haven't been crisp enough in one respect in this
discussion. Let me try to explain, even in my current jet-lagged state:

IMHO the goal of taking IPv6 to Internet Standard is to freeze a version of
the spec that guarantees *Internet-wide* interoperability. We know that there
are several challenges to Internet-wide interoperability:

#1. The flow label. There are agreed compromises in RFC6437.
#2. The traffic class field. That's a complicated story, basically solved
because RFC2474 defines the DSCP as locally significant and mutable.
#3. DPI beyond the 40 byte header. That has too many aspects for a single
email, but the fact is that the Internet is not transparent to arbitrary
extension headers. That can break PMTUD and/or fragmentation, among other
things. Again there are some compromises in RFC7045 but the problems
remain.
#4. Others that I have forgotten...

So, for *Internet-wide* interoperability, I think we must mitigate #3
as much as possible and I think that is why we should forbid extension
header manipulation.

However, for both the flow label and the traffic class we have got round
the problem:

For the flow label, we have language like:

"  A node that forwards a flow whose flow label value in arriving
   packets is zero MAY change the flow label value.
   ...
   o  The option to set the flow label in a forwarding node, if
      implemented, would presumably be of value in first-hop or ingress
      routers.
   ...
   In situations where the covert channel risk is considered
   significant, the only certain defense is for a firewall to rewrite
   non-zero flow labels.  This would be an exceptional violation of the
   rule that the flow label, once set to a non-zero value, must not be
   changed."

In other words, the flow label may be created by a router and may be
overwritten by a firewall.

For the traffic class, we have language like:

"  Nodes MAY rewrite the DS field as needed to provide a desired local
   or end-to-end service.  Specifications of DS field translations at DS
   boundaries are the subject of service level agreements between
   providers and users, and are outside the scope of this document."

In other words, the traffic class may change en route and in particular
at administrative boundaries.

To me the long-term solution for extension headers has to be along the
same lines - but it's complicated, because inserting, deleting or
modifying extension headers has more profound implications for
Internet-wide interoperability than either the flow label or the
traffic class. There are implications for fragmentation, PMTUD,
DPI, and probably more. So I don't see how we resolve them in the
short term. It's the tussle between that and one particular application
for locally-significant extension headers that has led us to this
lack of consensus.

An approach that was discussed and rejected for the flow-label was
to write specific language about domain-specific use of the flow
label. As far as I can see, we only have two choices in the present
case:

1) Write some specific language about domain-specific use of extension
headers.
2) Declare rough consensus for the present text and defer the question
of domain-specific extension headers until later.

OK, it goes against my preference, but here is some text for 1):

   Normally, extension headers are not 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. 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.

   There are two exceptions to this process.

   1. The Hop-by-Hop Options header 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.

   2. In a given administrative domain, locally significant extension
   headers may be inserted and deleted, if and only if any packet
   leaving the given domain is strictly identical to the packet prior
   to such insertion and removal.

(This can be justified in a Standard because it is based on running
code, as far as I know.)

Regards
   Brian

---

From: "C. M. Heard" <[email-masked]>
Date: Mon, 25 Jul 2016 21:18:02 -0700

On Mon, Jul 25, 2016 at 12:36 PM, Michael Richardson <[email-masked]> wrote:
> C. M. Heard <[email-masked]> wrote:
> Right, they go back to the big-bank Cisco PIX firewall, which discards all
> the ICMPs, because "security".  So what does it matter?

Because not every node is behind such a (brain-dead) firewall.

//cmh

---

From: "C. M. Heard" <[email-masked]>
Date: Mon, 25 Jul 2016 21:37:30 -0700

>   to such insertion and removal.

If we do this, could we a least also add text requiring said administrative
domain to prevent ICMP error messages relating to the inserted header
from being sent to the original source of the packet? And that the
header insertion be done in such a way so as to not break PMTUD?

//cmh

P.S. I am having a hard time seeing why the SPRING proponents
are fighting so hard for header insertion, since they have already
agreed to use encapsulation, in agreement with the text in
https://tools.ietf.org/html/draft-ietf-6man-rfc2460bis-01#page-7

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 26 Jul 2016 18:45:14 +1200

> header insertion be done in such a way so as to not break PMTUD?

I think those would be problems that could only harm hosts inside the private
domain. Do we care, in the Internet-wide interoperability spec?
(But indeed, my preference is to leave that analysis until later, i.e.
not make this change. However, I'm a compromise seeker.)

> https://tools.ietf.org/html/draft-ietf-6man-rfc2460bis-01#page-7

Um, something about running code...

   Brian

---

From: Steven Blake <[email-masked]>
Date: Tue, 26 Jul 2016 03:15:50 -0400

> at administrative boundaries.

[snip]

>    to such insertion and removal.

Identical except for possible changes to the flow label and traffic 
class field, as described above?  And the hop limit field, obviously.  
"Strictly identical" could be misinterpreted here.

> (This can be justified in a Standard because it is based on running

Aside: I assume we are still calling it the "traffic class" field 
instead of DS field (2474, 3260) + ECN field (3168) because those RFCs 
are only at Proposed?

Regards,

// Steve

---

From: "Stefano Previdi (sprevidi)" <[email-masked]>
Date: Tue, 26 Jul 2016 07:45:03 +0000

> On Jul 25, 2016, at 8:18 PM, [email-masked] wrote:
> 
> Stefano,
> 

just for me to understand. Leave any text regarding header insertion out of scope of rfc2460bis isn’t an option ?

> As an observation; the text we are discussing is not protocol specification, it is protocol politics.

indeed and that’s why I asked if the option to leave this outside the scope is realistic.

> And while I believe enshrining our values into protocols is fundamental to IETF work, - like routers not being allowed to  look beyond the IPv6 header, or the 64 bit boundary, it is always navigation in rocky waters.

knowing that routers do already do way more than what the “specs” allows them to do.

Hell is full of coders...

s.

---

From: Philip Homburg <[email-masked]>
Date: Tue, 26 Jul 2016 11:15:53 +0200

In your letter dated Tue, 26 Jul 2016 14:12:33 +1200 you wrote:
>    leaving the given domain is strictly identical to the packet
>    prior to such insertion and removal.

What about adding some text to the effect: headers can be inserted only
if there is a very low probability that an error ICMP will be generated based
on the packet with the header inserted. In particular the node that inserts
the header makes sure that the new packet will not trigger any MTU limits and
checks the packet for any parameter problems or routing issues.

---

From: Tim Chown <[email-masked]>
Date: Tue, 26 Jul 2016 10:30:15 +0000

Hi,

I’m still not clear as to where in any current IETF RFC/I-D there is text stating that a new EH should be inserted into an existing packet traversing a path, rather than encapsulated.

For the Type 4 RH used for Segment Routing, in draft-ietf-6man-segment-routing-header-01 it says in Section 2:

" While the source routing model defined in [RFC2460] doesn't mandate
   which node is allowed to insert (or modify) the SRH, it is assumed in
   this document that the SRH is inserted in the packet by its source.
   For example:

   o  At the node originating the packet (host, server).

   o  At the ingress node of an SR domain where the ingress node
      receives an IPv6 packet and encapsulates it into an outer IPv6
      header followed by a Segment Routing header.”

and then in Section 2.2.1:

"The outer header with the SRH is no different from any other
   tunneling encapsulation mechanism and allows a network operator to
   implement traffic engineering mechanisms so to efficiently steer
   traffic across his infrastructure."

So that implies encapsulation.

For the Type 3 RH used in RPL, in RFC6554 it says in Section 2:

“There are two cases that determine how to include an SRH when a RPL
   router requires the use of an SRH to deliver a datagram to its
   destination.

   1.  If the SRH specifies the complete path from source to
       destination, the router places the SRH directly in the datagram
       itself.

       the original datagram.”

Which also implies encapsulation.

So who is actually doing direct EH insertion into packets today? Am I misinterpreting the above documents, or are there use cases that are not being standardised in IETF documents?

Tim

---

From: Tim Chown <[email-masked]>
Date: Tue, 26 Jul 2016 10:37:27 +0000

> On 26 Jul 2016, at 07:45, Brian E Carpenter <[email-masked]> wrote:
> 

You’d probably then need to say “originating administrative domain”, to keep the side effects limited to the domain using header insertion. Though RFC7045 would now probably also see any leaking packets traverse all the way to their destination while carrying the unintended inserted EH (and probably then dropped by the site firewall…).

> Um, something about running code…

Ah, OK, well that’s the same question as my last email.  Perhaps this should be written up as an IETF doc, even if only individual submission / Experimental.

Tim

---

From: Michael Richardson <[email-masked]>
Date: Tue, 26 Jul 2016 07:40:20 -0400

...
    > OK, it goes against my preference, but here is some text for 1):

I like your text.

(I'm still uncomfortable about the corner we painted outself into which
concluded with 7045, but... that's out of scope)

I am also reluctant to specify this, but I prefer to specify this than leave
2460bis ambiguous.

    > (This can be justified in a Standard because it is based on running

And that's really important: we learn from the world and adapt.

---

From: <[email-masked]>
Date: Tue, 26 Jul 2016 12:38:56 +0000

Hi Tim, 

FWIW, a case we are investigating is documented in an individual draft: https://tools.ietf.org/html/draft-jacquenet-sfc-ipv6-eh-00#section-4 

EH insertion in that draft can be either be done with encapsulation or without encapsulation. Please note that this is an individual proposal and the IETF endorsed specification in NSH which does not rely on EHs.

Cheers,
Med

> -----Message d'origine-----
> De : ipv6 [mailto:[email-masked]] De la part de Tim Chown
> Envoyé : mardi 26 juillet 2016 12:30
> À : 6man WG
> Objet : Which use cases are using direct EH insertion?
> 
> Hi,
> 
> I'm still not clear as to where in any current IETF RFC/I-D there is text
> stating that a new EH should be inserted into an existing packet
> traversing a path, rather than encapsulated.
> 
>       header followed by a Segment Routing header."
> 
> "There are two cases that determine how to include an SRH when a RPL
> So who is actually doing direct EH insertion into packets today? Am I
> misinterpreting the above documents, or are there use cases that are not
> being standardised in IETF documents?
> 
> Tim
>

---

From: [email-masked]
Date: Tue, 26 Jul 2016 15:17:44 +0200

Tim,

> So who is actually doing direct EH insertion into packets today? Am I misinterpreting the above documents, or are there use cases that are not being standardised in IETF documents?

Indeed, which is leaves me unconvinced that any changes are needed with regards to the perceived ambiguity.
Any proposal of header injection would have to stand on its own feet.

Cheers,
Ole

---

From: Mark Smith <[email-masked]>
Date: Wed, 27 Jul 2016 00:28:19 +1000

>>       destination, the router places the SRH directly in the datagram

This one sounds to me like it is saying routers insert the SRH into an
existing packet, as routers don't originate packets, hosts do (or the
host component of a router i.e., the control plane.).

---

From: Tim Chown <[email-masked]>
Date: Tue, 26 Jul 2016 15:36:20 +0000

Hi Mark,

> On 26 Jul 2016, at 15:28, Mark Smith <[email-masked]> wrote:
> 

I think this is the point that Michael was reviewing in draft-richardson-roll-useofrplinfo-2460bis-01, looking at a variety of flow scenarios, on the assumption it’s all encap with no direct insertion, i.e. his draft says "This document assumes the rule that a Header cannot be inserted or removed on the fly inside an IPv6 packet that is being routed.”  
 
>> Any proposal of header injection would have to stand on its own feet.

Best wishes,
Tim

---

From: Steven Blake <[email-masked]>
Date: Tue, 26 Jul 2016 16:16:53 -0400

On 2016-07-26 06:30, Tim Chown wrote:
> Hi,
> 
> I’m still not clear as to where in any current IETF RFC/I-D there is
> text stating that a new EH should be inserted into an existing packet

[snip]

> misinterpreting the above documents, or are there use cases that are
> not being standardised in IETF documents?
> 
> Tim

If I am reading it correctly, draft-brockners-inband-oam-transport-00 
"Encapsulations for In-band OAM Data" inserts a Hop-by-Hop extension 
header with OAM options at the ingress router of an administrative 
domain, and strips it at the egress router (Sec. 3).  I think that 
Comcast showed a demo of this protocol at Bits-n-Bites (but that demo 
may have used GUE encapsulation edge-to-edge; I don't recall exactly).

Regards,

// Steve

---

From: Hemant Singh <[email-masked]>
Date: Tue, 26 Jul 2016 19:39:07 -0400

A question related to  draft-brockners-inband-oam...

How does a router determine it is an egress router and strips the oam
options?   Is it because the packet destination matches an IP/IPv6 address
configured on the router?  Or is there a configuration needed on this
router to deem it as an egress router to oam options?

Thanks,

Hemant

On Tue, Jul 26, 2016 at 4:16 PM, Steven Blake <[email-masked]>
wrote:
> "Encapsulations for In-band OAM Data" inserts a Hop-by-Hop extension header
> with OAM options at the ingress router of an administrative domain, and
> strips it at the egress router (Sec. 3).  I think that Comcast showed a
> demo of this protocol at Bits-n-Bites (but that demo may have used GUE
> encapsulation edge-to-edge; I don't recall exactly).
>
>
> Regards,
>
> // Steve
>
>
>

---

From: "Shwetha Bhandari (shwethab)" <[email-masked]>
Date: Wed, 27 Jul 2016 05:20:23 +0000

>How does a router determine it is an egress router and strips the oam options?   Is it because the packet destination matches an IP/IPv6 address configured on the router?  Or is there a configuration needed on this router to deem it as an egress router to oam options?

The decision to add/remove the HbyH options/header is based on classification of flows and/or interfaces as entering/leaving the domain. In our current implementation of In-band OAM (in fd.io<https://gerrit.fd.io/r/gitweb?p=vpp.git;a=tree> ) it is done by pushing this configuration on the domain's perimeter nodes.

>  I think that Comcast showed a demo of this protocol at Bits-n-Bites (but that demo may have used GUE encapsulation edge-to-edge; I don't recall exactly).

In the demo it was purely IPv6 edge to edge no encap.

Thanks,
Shwetha

From: Hemant Singh <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, July 27, 2016 at 5:09 AM
To: Steven Blake <[email-masked]<mailto:[email-masked]>>, "Frank Brockners (fbrockne)" <[email-masked]<mailto:[email-masked]>>, Shwetha bhandari <[email-masked]<mailto:[email-masked]>>, "Carlos Pignataro (cpignata)" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: Tim Chown <[email-masked]<mailto:[email-masked]>>, 6man WG <[email-masked]<mailto:[email-masked]>>
Subject: Re: Which use cases are using direct EH insertion?

How does a router determine it is an egress router and strips the oam options?   Is it because the packet destination matches an IP/IPv6 address configured on the router?  Or is there a configuration needed on this router to deem it as an egress router to oam options?

Thanks,

Hemant

On Tue, Jul 26, 2016 at 4:16 PM, Steven Blake <[email-masked]<mailto:[email-masked]>> wrote:

If I am reading it correctly, draft-brockners-inband-oam-transport-00 "Encapsulations for In-band OAM Data" inserts a Hop-by-Hop extension header with OAM options at the ingress router of an administrative domain, and strips it at the egress router (Sec. 3).  I think that Comcast showed a demo of this protocol at Bits-n-Bites (but that demo may have used GUE encapsulation edge-to-edge; I don't recall exactly).

Regards,

// Steve

---

From: Hemant Singh <[email-masked]>
Date: Wed, 27 Jul 2016 08:57:07 -0400

If section 3.1.2 related to ingress, we have text that says "insertion of the
in-band OAM header is enabled at the required edge nodes by means of
configuration."  However, the same text does not exist in the egress
section in 3.1.4.  Why not add common text for ingress/egress before any of
these two sections start?

How does classification of flows signal to the egress router to strip
options?

thanks,

Hemant

On Wed, Jul 27, 2016 at 1:20 AM, Shwetha Bhandari (shwethab) <
[email-masked]> wrote:

>
> The decision to add/remove the HbyH options/header is based on
> classification of flows and/or interfaces as entering/leaving the domain.
> In our current implementation of In-band OAM (in fd.io
> <https://gerrit.fd.io/r/gitweb?p=vpp.git;a=tree> ) it is done by pushing
> this configuration on the domain's perimeter nodes.
>
>
>