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

[Mark Smith <[e-mail]>]

On 31 Oct. 2017 11:02, "Michael Richardson" <[e-mail]> wrote:


Tim, Tim and John, thanks again for taking on 6434bis.

Let me open a can of worms, now that the draft deadline has just passed :-)

We argued lots in producing RFC8200 that one solution for inserting headers
mid-way was to add an IPIP header.   If we really think that this is
operationally possible(*), then I think we need to write text in 6434bis to
make
it true.

For some uses of IPIP-based header insertion there can be clearly a node (a
router probably) which could then remove the newly inserted header, and the
IPIP header added can be addressed to that node (%).   This is an IPIP
tunnel.  I
believe that LISP does something like this, and many of us are familiar with
IPsec tunnel mode as well.

For many other uses, the only obvious target for the IPIP header is the same
destination address as what was originally there, and so a packet like:
            IP{src:A, dst: B} ULP

becomes
            IP{src:D, dst: B} IP{src:A, dst: B} ULP

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

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)


I don't think this decapsulation is forwarding. Forwarding is really just
what to do when receiving a packet with a DA that doesn't match the
device's address(es). Hosts drop them, routers see what the forwarding
table says to do with them.

The processing you're describing is passing the payload, post
decapsulation, to the payload processing module indicated by the payload
type field in the previous header.

In the case of IPinIP, the host supports the payload type of IPinIP or
protocol 4, and knows that a payload of that type gets submitted to the
IPv4 packet processing module. If the DA of the payload IP packet matches
the host's, then it should be processed the same way as the former outer
packet was. IPinIPinIP should be processed the same way as IPinIP.

Regards,
Mark.



There are also implications for security devices, but in most respects I
don't think that they are different than for extension headers.

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.

(*)- I think it's operationally possible, and draft-ietf-roll-useofrplinfo
     explains how to do it within the controlled environment of an LLN.
     I spent half the morning putting final touches to that...

(%)- for the cases where an "exit" node is easy to identify, and the traffic
     is guarantee to get to, doing a non-IPIP header insertion is even
easier
     to argue for.  Any arguments that the packet might "escape" being
     un-molested are arguments for why 6434bis has to deal with IPIP
headers.

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




--------------------------------------------------------------------
IETF IPv6 working group mailing list
[e-mail]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------