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

On 1 Nov. 2017 06:03, "Michael Richardson" <mcr+ietf@sandelman.ca> wrote:

Ole Troan <otroan@employees.org> 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.

I think we need to be clear about what is "inserting" is. To me, the word
"inserting" means inserting to into something that already exists and has
previously been created - cut apart, insert, glue back together.

IPinIP in the network is not doing insertion. It is adding by encapsulating
with a new IP header. That's the way we add information at all other layers
of the stack.

IPinIP in a host is, for some reason or other, not encoding all of the
information in the first IP header, so it adds another one to carry it.
IPsec tunnel mode would be an example.

IPsec transport mode isn't "inserting" either. The host sending the IPsec
transport mode packet builds the entire thing, and adds the AH/ESP header
at the appropriate time during the encapsulation process as the IPsec
packet is built before being put on the wire.

So truly "inserting" (cut, insert, glue) into an existing packet is not
something that has been part of any IETF protocol as far as I'm aware.

Regards,
Mark.

One of 6463 or 2460/8200 must be wrong.

Essentially 8200 says to do something that doesn't work.
Should we be at all surprised that there is was much push to do it a
different way?

If we don't fix 6434 to make it work, then our hard fought compromise in
8200
is moot.

ps: I'm not advocating for changing 8200.

--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------