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

Michael Richardson <> Wed, 01 November 2017 20:25 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4028713F5D8 for <>; Wed, 1 Nov 2017 13:25:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id fQvKYoM_r7Z3 for <>; Wed, 1 Nov 2017 13:24:58 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7AB3413F54D for <>; Wed, 1 Nov 2017 13:24:58 -0700 (PDT)
Received: from ( [IPv6:2607:f0b0:f:2::247]) by (Postfix) with ESMTP id E072420089; Wed, 1 Nov 2017 16:25:51 -0400 (EDT)
Received: from (localhost [IPv6:::1]) by (Postfix) with ESMTP id 8F5E381DB3; Wed, 1 Nov 2017 16:24:57 -0400 (EDT)
From: Michael Richardson <>
To: Mikael Abrahamsson <>
cc: 6man WG <>
Subject: Re: Updating to RFC6434 to deal with 8200-style header insertion by IPIP
In-Reply-To: <>
References: <> <> <>
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: Wed, 01 Nov 2017 16:24:57 -0400
Message-ID: <>
Archived-At: <>
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 01 Nov 2017 20:25:00 -0000

Mikael Abrahamsson <> 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

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 <>ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-