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

[Mark Smith <[e-mail]>]

On 30 March 2017 at 07:55, Stefano Previdi (sprevidi)
<[e-mail]> wrote:
>
>> On Mar 28, 2017, at 10:07 PM, Mark Smith <[e-mail]> wrote:
>>
>> They're missing the difference between encapsulation and insertion.
>
>
> 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).

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 entered the domain.

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/"



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

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.



>>
>> 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.
>
>
> 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.
>
>
>> While the IPv6 packet traverses the 6PE domain, the IPv6's packet size
>> 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.
>
>
>> 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.
>
>
> 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
>> 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.
>
>
> again, not really in this case: the SA is untouched and it represents the ingress node of the controlled domain.
>
>
>> 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.
>
>
> 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.

> s.
>
>

Regards,
Mark.

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