Re: Updating to RFC6434 to deal with 8200-style header insertion by IPIP

[Tom Herbert <[e-mail]>]

On Mon, Nov 6, 2017 at 8:15 AM, Fernando Gont <[e-mail]> wrote:
> On 10/31/2017 04:02 PM, Michael Richardson wrote:
>>
>> Ole Troan <[e-mail]> wrote:
>>     > Without having thought very much about it... I do think requiring a
>>     > host to accept tunnelled packets to itself by default or not, requires
>>     > further considerations.
>>
>> I agree: it requires further consideration.
>>
>>     > I am aware of no implementation that would support this. I would also
>>     > be worried about this opening the door for "alternate" paths into the
>>     > host stack.
>>
>> I agree. Nobody does it this way.
>> Yet 8200 (and 2460 before it) says that this is the way to insert headers.
>
> No. EHs are not inserted or removed. When you do IPinIP, you are
> creating a brad-new packet, *not* inserting EHs in the existing packet.
>
I agree.

I think the sticking point is going whether a node can blindly perform
IP-IP encapsulation on packets to arbitrary destinations (as opposed
to using IP-IP for explicitly tunneling across a network). This
requires the assumption that all nodes in the downstream path will
forward a packet with IP-IP and the added extension headers, and that
the destination will accept such packets. The problem is that if a
packet is dropped because of the encapsulation or EHs and no ICMP
error is returned to the encapsulator then there is no way to recover.
The original source host might see packets being dropped on a
connection but will have no idea why. The encapsulator sees no problem
and so it won't modify its behavior.

Tom