Re: EH end encapsulation in 2460bis

On 14/04/2016 11:59, Fred Baker (fred) 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.
> 
> 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.

Agreed. And to Tom's question:

>> For instance, is expected that there is
>> some process of moving/copying certain of the original EHs to the
>> outer headers (like HBH, routing)?

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

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