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

[Michael Richardson <[e-mail]>]

Mikael Abrahamsson <[e-mail]> wrote:
    > On Mon, 30 Oct 2017, Michael Richardson wrote:

    >> And I think that most host stacks discard such things unless configured to
    >> expect a tunnel from D.

    > Agreed.

    >> What to do?
    >>
    >> I'd like to make it clear that the above construct is valid and that hosts
    >> SHOULD process it to remove the first IPIP hader and then process the packet
    >> as normal, even if "forwarding" is off. (If inner dst: is *NOT* B, then discard)

    > Ok. If it's configured to expect this kind of IPIP tunnel,
    > agreed. Automatically, I don't think it should do this. It should not be
    > default behaviour. Otoh I agree that ripping of a header isn't "forwarding"
    > and shouldn't count as such. A 6to4 enabled host with forwarding disabled,
    > receiving a 6to4 packet addressed to itself, should indeed take off the
    > header and then process the inner packet.

    > If the OS comes by default with 6to4 enabled, then I expect it to be able to
    > handle 6to4 packets coming to it. I wouldn't expect it to behave this way if
    > 6to4 is turned off, then it should just drop the packet.

Fair enough for 6to4.  Having 6to4 on or off is a useful setting that the
end-host should control, and for which the end-host gets some defined
benefit.

Removing redundant IPIP headers at the end-host provides no benefit to the
end-host.  The end-host does this in order to facilitate some unknown service
in the middle that did something.  If we want to enable such things to work
without prior permission (cf: "permissionless innovation") then we need to
fix hosts to do this.

There is also a hack that we could employ to sit on the fence.
We could decide that the destination address should no longer be B, but
instead it could be some well known same-prefix-as-B::anycast-IID,
and have the last router remove the outer IPIP header.
This seems gross in many many ways, but might make everyone happy.

    >> As an aside, it would also be nice if we could say that an IPsec AH header
    >> with an unknown SPI should be skipped as if it wasn't even there (including
    >> any subsequent IP header as above..)  This is essentially a similar
    >> situation.  I suspect that this statement is even more controversial.

    > If the device isn't configured to do IPsec (even by default), then I don't
    > think it should do what you describe.

Yet we skip other extension headers in order to find the ULP.
In fact, a host that has *NO* IPsec code *at all* will skip it as an unknown
header....  Because we got this wrong, we couldn't use AH to secure ND or any
other multicast (like OSPF) without causing of a flag day.  AH became totally
USELESS.  It was sad.

--
Michael Richardson <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-