Subject: EH end encapsulation in 2460bis

From: Tom Herbert <[email-masked]>
Date: Wed, 13 Apr 2016 16:03:10 -0700

Hello,

>From draft-ietf-6man-rfc2460bis-04

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

It is unclear to me how/rather IP encapsulation can meet the
requirements or at least the intent of a node wanting to insert
extension headers. For instance if a middlebox is presented a packet
with EHs ABC and it wishes to insert EH X, it's intent might be to
create a packet with EHs ABXC. I don't see how this can generally be
expressed with encapsulation. For instance, is expected that there is
some process of moving/copying certain of the original EHs to the
outer headers (like HBH, routing)?

Thanks,
Tom

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Wed, 13 Apr 2016 23:59:29 +0000

I actually looked pretty hard at this in https://tools.ietf.org/html/draft-ietf-6man-hbh-header-handling-00. My segment-routing colleagues wanted pretty badly to insert an SR header at some point in the network, and then remove it somewhere else before delivery to the destination.

Working through potential failure cases, what worried me was the security header. Suppose, for example, that the inserted SR header would have to be removed before being given to the addressed destination, but the addressed destination was an anycast address? In such a case, the system that will ultimately respond to the packet advertises itself as "a" right router capable of forwarding the packet to that address. So, fine, I give the packet to the "router", and the receiving system realizes that the destination address is one of its own, and so receives it as a message addressed to it. Oops; we tripped over an assumption.

At IETF 94, I tried to make my SR colleague's point, and Bob Hinden told me that they had already vacated the field, leaving me with my pants around my ankles. Thanks, guys.

But that is fundamentally the point. We need a solution that has no sticky failure cases, and delivering the actual packet sent is the only one that presents itself. Encapsulation does that. Anything else has to prove the case.

> On Apr 13, 2016, at 4:03 PM, Tom Herbert <[email-masked]> wrote:
> 
> Hello,
> 
> --------------------------------------------------------------------
> 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, 14 Apr 2016 12:58:25 +1200

Agreed. And to Tom's question:

>> For instance, is expected that there is

Afaics, the encapsulator can do whatever it wants as long as the new
IPv6 header is valid. It's creating a brand new IP packet that happens
to contain the incoming one, so there's no reason it can't copy some of
the extension headers. I'm not sure that it *should* do that, if the
goal is to get through a part of the Internet that discards certain
header types.

    Brian

---

From: "Ray Hunter (v6ops)" <[email-masked]>
Date: Thu, 14 Apr 2016 10:12:47 +0200

> outer headers (like HBH, routing)?
A middleware box can't possibly know all the details of the entire 
downstream topology/MTU limitations/load balancing etc.

So it would seem to me that choosing for encapsulation implies that 
there will be another middleware box somewhere further down the path 
that will perform an inverse de-encapsulation, so that the original 
packet gets delivered to the final recipient as sent by the sender. 
That's how transports like MPLS and WAN optimisation work today, and 
certainly feels like the right thing to do to me.

Otherwise, if an extension header is going to be that valuable to ensure 
good communications, the source node can insert it itself IMHO.

My own €0.02 worth is that inserting/deleting/or otherwise messing 
around with packet headers, just makes operations much more difficult. 
[written by someone who experienced the horror of L2 bridging FDDI to 
Ethernet first hand]

-- 
regards,
RayH
<https://www.postbox-inc.com/?utm_source=email&utm_medium=siglink&utm_campaign=reach>

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 14 Apr 2016 10:25:43 +0200 (CEST)

On Wed, 13 Apr 2016, Fred Baker (fred) wrote:

> At IETF 94, I tried to make my SR colleague's point, and Bob Hinden told 
> me that they had already vacated the field, leaving me with my pants 
> around my ankles. Thanks, guys.

Just so I understand this 100%. The SR guys no longer want to do SR header 
insertion and removal when entering/leaving the SR domain?

So SR is now only encap of entire packet? Either in a new IP packet or 
using MPLS?

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: "Stefano Previdi (sprevidi)" <[email-masked]>
Date: Thu, 14 Apr 2016 08:56:24 +0000

> On Apr 14, 2016, at 10:25 AM, Mikael Abrahamsson <[email-masked]> wrote:
> 
> Just so I understand this 100%. The SR guys no longer want to do SR header insertion and removal when entering/leaving the SR domain?

current implementations of Segment Routing over IPv6 dataplane (aka: SRv6) do SRH insertion at ingress of the domain and SRH removal at egress.

> So SR is now only encap of entire packet? Either in a new IP packet or using MPLS?

not exactly. All SRv6 implementation I know of, do header insertion only.

Thanks.
s.

---

From: Mark Smith <[email-masked]>
Date: Thu, 14 Apr 2016 19:59:56 +1000

>
> So it would seem to me that choosing for encapsulation implies that there
will be another middleware box somewhere further down the path that will
perform an inverse de-encapsulation, so that the original packet gets
delivered to the final recipient as sent by the sender. That's how
transports like MPLS and WAN optimisation work today, and certainly feels
like the right thing to do to me.

A insight Brian C. pointed out in the context of the many addresses per
host draft is that tunnelling devices are not middle boxes, they're
actually hosts, as they're the end points for the IP packets that are
created and sent or received and disposed of during the performance of the
tunneling function. The payload, which happens to be another IP packet, is
the tunnelling application data.

Any EHs that are created after the outer IPv6 header and before the payload
IPv6 packet are valid by RFC2460bis, because they're being created by the
host originating the packet.

Regards,
Mark.

>
> My own €0.02 worth is that inserting/deleting/or otherwise messing around
with packet headers, just makes operations much more difficult. [written by
someone who experienced the horror of L2 bridging FDDI to Ethernet first
hand]

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 14 Apr 2016 12:18:49 +0200 (CEST)

On Thu, 14 Apr 2016, Stefano Previdi (sprevidi) wrote:

> current implementations of Segment Routing over IPv6 dataplane (aka: 
> SRv6) do SRH insertion at ingress of the domain and SRH removal at 
> egress.

https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-01

4.1.

"An SR domain ingress router encapsulating a received IPv6 packet
       into an outer IPv6 header followed by an SRH."

Does this mean the outer header is a new header, and the received IPv6 
packet is completely (and unchanged) encapsulated into a new IPv6 header 
(with DA being the SR exist node) and SRH?

So SR is now tunneling only, it's never "take existing received packet 
IPv6 header, insert SRH after existing received packet header, then insert 
rest of original packet EH" (which would be header insertion instead of 
creating a tunnel packet)?

The above draft could be a lot clearer, for instance not saying "an outer 
IPv6 header".

---

From: "Stefano Previdi (sprevidi)" <[email-masked]>
Date: Thu, 14 Apr 2016 15:01:47 +0000

> On Apr 14, 2016, at 12:18 PM, Mikael Abrahamsson <[email-masked]> wrote:
> 
> Does this mean the outer header is a new header, and the received IPv6 packet is completely (and unchanged) encapsulated into a new IPv6 header (with DA being the SR exist node) and SRH?

yes.

> So SR is now tunneling only, it's never "take existing received packet IPv6 header, insert SRH after existing received packet header, then insert rest of original packet EH" (which would be header insertion instead of creating a tunnel packet)?

it is correct. The current draft assumes only encapsulation.

However, this does not reflect the reality o implementation and deployments where the SRH is in fact inserted after the received ipv6 header.

s.

> The above draft could be a lot clearer, for instance not saying "an outer IPv6 header".
> 
> --

---

From: "Ray Hunter (v6ops)" <[email-masked]>
Date: Thu, 14 Apr 2016 17:14:40 +0200

> Mark Smith <mailto:[email-masked]>
> 14 Apr 2016 11:59
>
>
> On 14 Apr 2016 6:13 PM, "Ray Hunter (v6ops)" <[email-masked] 
> <mailto:[email-masked]>> wrote:
> >
> >
> >
> > Tom Herbert wrote:
> >>
> >> Hello,
> >>
> A insight Brian C. pointed out in the context of the many addresses 
> per host draft is that tunnelling devices are not middle boxes, 
> they're actually hosts, as they're the end points for the IP packets 
> that are created and sent or received and disposed of during the 
> performance of the tunneling function. The payload, which happens to 
> be another IP packet, is the tunnelling application data.
>
> Any EHs that are created after the outer IPv6 header and before the 
> payload IPv6 packet are valid by RFC2460bis, because they're being 
> created by the host originating the packet.
>
> Regards,
> Mark.
>
I agree with that.

An IPv6 in IPv6 tunnel could also just as well be considered a special 
case of what I suggested above for middleware boxes.

However, if you're going to do that, you're probably going to want to 
anyway re-use an existing mechanism like GRE RFC2784, or Generic Packet 
Tunneling of IPv6 in IPv6 RFC2473.

In any case, a tunnel always has at least one peer end point, where the 
original packet is de-encapsulated back to its original form as sent by 
the original sender (without any additional extension headers).

I think Fred pointed out the danger of mixing the semantics of "payload" 
and "encapsulation" rather nicely: any leaks between the two can create 
nasty side affects.
>
> > Otherwise, if an extension header is going to be that valuable to 
> ensure good communications, the source node can insert it itself IMHO.
> >

---

From: Tom Herbert <[email-masked]>
Date: Thu, 14 Apr 2016 08:32:08 -0700

> I actually looked pretty hard at this in https://tools.ietf.org/html/draft-ietf-6man-hbh-header-handling-00. My segment-routing colleagues wanted pretty badly to insert an SR header at some point i…
I think my real question is a bit more pedantic. Does any mitigation
for the inability to insert extension headers even need to be
suggested in 2460bis? It does not seem like this is normative to the
protocol.

Tom

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Thu, 14 Apr 2016 16:11:32 +0000

My understanding - this from Bob - is that they agreed to encapsulate in an IPv6 header with an SR header. I spoke with the about it and they said they had agreed to encapsulate, but I don't have details on that.

> On Apr 14, 2016, at 1:25 AM, Mikael Abrahamsson <[email-masked]> wrote:
>

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 15 Apr 2016 08:35:10 +1200

> However, this does not reflect the reality o implementation and deployments where the SRH is in fact inserted after the received ipv6 header.

Not being the protocol police, the IETF can't do anything about what consenting
adults do in a private network. We write standards for interop across the
Internet.

Private use of the DSCP field has always been foreseen, but in general the IETF
hasn't liked legitimising private uses of other parts of the IP header, for fear
they would escape. But if we want to legitimise private use of EH, we could.

   Brian