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

Michael Richardson <mcr+ietf@sandelman.ca> Tue, 31 October 2017 00:01 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65B7A13FC7C for <ipv6@ietfa.amsl.com>; Mon, 30 Oct 2017 17:01:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vvj2YDeklG8L for <ipv6@ietfa.amsl.com>; Mon, 30 Oct 2017 17:01:29 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C12A5CEDE for <ipv6@ietf.org>; Mon, 30 Oct 2017 17:01:25 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 12D942025C for <ipv6@ietf.org>; Mon, 30 Oct 2017 20:02:13 -0400 (EDT)
Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 1B0A680D54 for <ipv6@ietf.org>; Mon, 30 Oct 2017 20:01:25 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: 6man WG <ipv6@ietf.org>
Subject: Updating to RFC6434 to deal with 8200-style header insertion by IPIP
In-Reply-To: <CAOSSMjUVCSBjbYu3bc7DU+edz2+0+RvU_AMi4FNn2n2075kk9g@mail.gmail.com>
References: <CAOSSMjUVCSBjbYu3bc7DU+edz2+0+RvU_AMi4FNn2n2075kk9g@mail.gmail.com>
X-Mailer: MH-E 8.6; nmh 1.7-RC3; GNU Emacs 24.5.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha256"; protocol="application/pgp-signature"
Date: Mon, 30 Oct 2017 20:01:25 -0400
Message-ID: <6286.1509408085@obiwan.sandelman.ca>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/4gcM3fEIrm5p1WA3__Lkz8BifiA>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 31 Oct 2017 00:01:32 -0000

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)

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 <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-