Subject: draft-voyer-6man-extension-header-insertion

From: Mark Smith <[email-masked]>
Date: Wed, 29 Mar 2017 07:07:51 +1100

They're missing the difference between encapsulation and insertion.

The increase and decrease in "packet" size that is occurring in their
6PE example is as the PDU crosses layer boundaries due to
encapsulation or decapsulation. This is occurring as the PDU travels
vertically between layers. From the IPv6 perspective, the 6PE layer is
a link layer below the network layer.

While the IPv6 packet traverses the 6PE domain, the IPv6's packet size
and structure is not changed in any way.

EH insertion is increasing the PDU size and changing the packet
structure while the packet travels horizontally within the IPv6 layer.
That will break things if the destination host doesn't expect the
packet size or structure to change, and they don't, because it is not
a described "within layer" packet processing behaviour in RFC2460. The
destination host expects that the packet received has a structure and
size that is the same as sent by the device identified in the source
address field, which is the host that originated the packet.

EH insertion makes the source address field both meaningless and
holding an incorrect value while the inserted EH is present. A
specification for EH insertion would need to state this very clearly.
Many of the negative consequences of EH insertion are because it makes
the packet's source address field meaningless and holding a incorrect
value.

The only things that are permitted to change while an IPv6 packet is
in flight (within the IPv6 layer) are values of a defined set of
fields specified in RFC2460 e.g., hop limit, flow label, traffic
class. Only field values change, no fields are added or removed - the
packet's structure and size stays the same after these modifications
if or when they occur.

Regards,
Mark.

---

From: "Stefano Previdi (sprevidi)" <[email-masked]>
Date: Wed, 29 Mar 2017 20:55:00 +0000

> On Mar 28, 2017, at 10:07 PM, Mark Smith <[email-masked]> wrote:
> 

not really:

. a packet is received at ingress of the controlled domain
. the packet is encapsulated into a new outer ipv6 header where SA/DA are internal to the domain.
. from now on:
    . this packet is a packet sourced and destined within the controlled domain.
    . the original packet is encapsulated and will remain untouched/unmodified (i.e., noting will be inserted into the original packet).
. a packet sourced and destined internally in the controlled domain can safely be increased in its size and can be safely have EHs inserted by transit nodes.
. when the packet reaches the egress node of the controlled domain, the outer encapsulation and any inserted EH are removed. IOW, the packet that leaves the domain is exactly the same packet that entered the domain.
. the size of the packet increased inside the domain due to encapsulation of course but also due to EH insertion while in transit in the domain. The MTU problem doesn’t exist in reality because the MTU of interfaces in the controlled domain is roughly 4 times what is at the ingress.
. the point of the draft is to say that if the packet is sourced and destined within a controlled domain, it is safe to allow insertion of EHs by transit nodes.

once again: the EH insertion happens into the outer header, not into the original packet.

> a link layer below the network layer.

the example of 6pe outlines the fact that the packet, while transiting within a domain, can  increase in its size due to label stack being pushed.

> and structure is not changed in any way.

the same is in our approach:

. the original packet is encapsulated into an outer header and its size will not change.
. the encapsulating packet will get EH inserted.

> holding an incorrect value while the inserted EH is present.

not really:
. the SA is untouched by the EH insertion. The SA is the address of the ingress node of the controlled domain.
. the DA is updated with the first segment of the EH (we assume the inserted EH is the SRH).
. the DA is updated at each segment

> A

again, not really in this case: the SA is untouched and it represents the ingress node of the controlled domain.

> packet's structure and size stays the same after these modifications

I understand what rfc2460 specified and the reason of our draft is to explain that things have changed in the last 20 years and we should take them into consideration.

s.

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

---

From: Mark Smith <[email-masked]>
Date: Fri, 31 Mar 2017 07:06:24 +1100

>     . the original packet is encapsulated and will remain untouched/unmodified (i.e., noting will be inserted into the original packet).

So that is the transit case, and yes, that packet is left as sent by
it's originating host.

The 6PE example is the one that is claiming that "packet" is changing
in size, and that is not correct.

"While transiting in the core, the size of the label stack (hence
      the size of the packet)"

Any time this draft mentions "packet" without context, it is going to
be read as "IPv6 packet" because this draft is an IPv6 draft and this
is an IPv6 working group.

While that might sound like I'm being pedantic, this 6PE example seems
to be being used to show that 6PE already changes the size of the IPv6
packet, and therefore changing IPv6 packet sizes mid-flight is normal
and acceptable.

> . a packet sourced and destined internally in the controlled domain can safely be increased in its size and can be safely have EHs inserted by transit nodes.

I don't agree with that statement. What if the inserted EH isn't
actually removed when it should be?

The domain already supports IPv6-in-IPv6 encapsulation, going the
transit packet example. Why complicate things by also having the same
domain support insertion, when already supported IPv6-in-IPv6
encapsulation can be used to achieve the same outcome?

EH insertion and DA address swapping seem to be to be far more
complicated and therefore expensive and error prone operations than
network-layer to link-layer (where IPv6 is also being used as a
link-layer) type encapsulation/decapsulation.

> . when the packet reaches the egress node of the controlled domain, the outer encapsulation and any inserted EH are removed. IOW, the packet that leaves the domain is exactly the same packet that e…

Your specification will say that, probably as a MUST. The trouble is
that implementations don't always behave as specified. "In theory,
practice and theory are the same. In practice they're not."

If a later router or host receives a packet with an EH that hasn't
been removed when it should have been, what will happen? That
behaviour isn't currently specified.

We know that protocols assume that the received packet's structure and
most of its field values (e.g., excluding Hop Limit, flow label etc.)
were set by the device specified in the source address field. If an
inserted EH is not removed, and you can't guarantee that, then devices
are receiving packets that are corrupt by the current specifications.

I think this is a change that is violating Postel's Robustness principle.

I think one meaning of "Be conservative with what you send," is don't
send something that might break somebody else's devices.You might
argue you aren't, because your specification will say the inserted EH
MUST be removed. However, you can't guarantee that, and that is why
Jon said, paraphrasing, "don't send them in the first place/"

> once again: the EH insertion happens into the outer header, not into the original packet.

The outer IPv6 packet is also an IPv6 packet - the inner IPv6 is
really just application payload (tunnelling is really just a
host-to-host application). So inserting an EH into the outer IPv6
packet is also violating the IPv6 specifications.

> I understand what rfc2460 specified and the reason of our draft is to explain that things have changed in the last 20 years and we should take them into consideration.

That's the thing that is missing. There is an assertion that inserting
EHs is required (a much stronger word than "preferred"), yet no
explanation of why it is required or essential.

The use of the word "required" implies that the inserting EH is
essential for this to work. I don't think it is, encapsulation could
achieve the same outcome, and it is an existing, well known method
that won't interact unexpectedly with existing IPv6 implementations.

Regards,
Mark.

Regards,
Mark.

---

From: "Stefano Previdi (sprevidi)" <[email-masked]>
Date: Thu, 30 Mar 2017 20:55:36 +0000

> On Mar 30, 2017, at 10:06 PM, Mark Smith <[email-masked]> wrote:
> 

6PE encapsulates the packet into a label stack

SRv6 encapsulates the packet into an outer IPv6 header and suhc outer IPv6 header may have SRH inserted by nodes in transit.

Bottom line, the situation here the packet increases is not new (6PE).

> is an IPv6 working group.

still the assertion is correct.

> packet, and therefore changing IPv6 packet sizes mid-flight is normal

no. It means it’s not new and therefore issues have been already addressed (e.g., MTU).

> actually removed when it should be?

a packet "destined within the domain" implies that at the edge of the domain the outer encapsulation is removed (with the underneath SRH). Otherwise it doesn’t fit the definition of “destined within the domain”. 

> encapsulation can be used to achieve the same outcome?

source routing by stacking ipv6 outer headers ? It’s a joke, right ? Maybe you should look a bit deeper on what segment routing is about:
	draft-ietf-spring-segment-routing
	draft-ietf-spring-segment-routing-mpls
	RFC7855
	draft-ietf-spring-segment-routing-central-epe
	draft-ietf-6man-segment-routing-header
	draft-filfils-spring-srv6-network-programming

> link-layer) type encapsulation/decapsulation.

sorry, I don’t follow you. SR re-uses the source routing paradigm where the source routed (loose) path is encoded as a list of segments which are used to override the DA at each segment hop. I don’t know what, in this, is complicated.

> practice and theory are the same. In practice they're not.”

practical experience showed that implementation errors may happen at each level, no matter what you write in your specs. En encapsulated packet (i.e., without any EH) may also “escape” in some places where we don’t want it to go.

Operators have learned over the year how to confine within the domain such issues.

> behaviour isn't currently specified.

again and again: the outer header contains SA/DA inside the domain so the packet can’t reach any address other than internal to the domain.

> are receiving packets that are corrupt by the current specifications.

that device is internal to the domain so the effects are anyway mitigated.

> I think this is a change that is violating Postel's Robustness principle.

that’s not true.

Anyway, history is full of principle violations...

> packet is also violating the IPv6 specifications.

sure. the draft proposes a context/use-case where this is safely done: internal to a controlled domain.

> explanation of why it is required or essential.

I will elaborate a more on this in the next revision.

> essential for this to work.

yes. It is required to take the best benefit out of source routing in ipv6.

> I don't think it is, encapsulation could
> achieve the same outcome,

it can’t.

> and it is an existing, well known method

encapsulation is a very limited tool that will do very limited things that may have worked in the past 20 years but today modern networking requirements raised the bar... a bit more.

s.