Re: EH end encapsulation in 2460bis

On Wed, Apr 13, 2016 at 4:59 PM, Fred Baker (fred) <fred@cisco.com> wrote:
> 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.
>
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

> 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 <tom@herbertland.com> wrote:
>>
>> 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
>>
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> ipv6@ietf.org
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>