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

Brian E Carpenter <> Tue, 31 October 2017 01:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 66B9013F9B9 for <>; Mon, 30 Oct 2017 18:08:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id qpucbPbtmOgc for <>; Mon, 30 Oct 2017 18:08:19 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400e:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3BCB813FB60 for <>; Mon, 30 Oct 2017 18:08:19 -0700 (PDT)
Received: by with SMTP id g6so13188067pgn.6 for <>; Mon, 30 Oct 2017 18:08:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=6/lIXJWPJs1M52r8JXQHX2dPUdViKnKuarG8mO+6cYs=; b=HioffBd+4g+s+qQ5QmziT6aGgksk1QdBfBPbmd9St6ziWasHmsd/RrtiyDVc53rF0j 7ON073pirqzMPKq5wc+wFuECl4+H2DjbMxEpV68PTvGY4Z8IjHk+SYnIK8lXUK9l7tmq GqZWdFwaqcewVbNLNIzvxrV8zAd+YKi9nYv1vHwC64bHBYQuMEaw+76YTRh0BQVqGhjA SylLKPhjPMGS7R+Gu/9zFPjFmpL0PtAfiUPPSLoiJojIJM6HUjD+StJCY707VZhWFKeP YxDVJUK3XVBgA9iqGPAOJroUG4a1HYD/oW5+JUKMVeoIbItawbtK8aUaUcF/8B0V4LVc zfuQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=6/lIXJWPJs1M52r8JXQHX2dPUdViKnKuarG8mO+6cYs=; b=PmTHzdkpSzlhEF+DYs+cjO1sbhy1dHvbTbfT4zDlW63Ho/CHwxtp6TMgfq9RK2qADJ U+eRT57JENc3j/vtgFRGLlDZNNKGoz75Fh5TcFb7lgHoqkUK6yFafXOpR/761nJzusQ7 VSLbDfpYgW1beWCFRzjl7dG1crqIZ773tVIMUKl9h1MpY3372vcTznOsjx3ebUQFwce3 Zlo+mGyYMrjNFEb3nFHcO+LLb65tr0O4jQDsRVBhdmbnrwVDccPcLnzz4OOEZylNjJ88 /Cxv3V/mUTFuIAEvpyw7jOEPN83TisGtisfxiKEIWnP3ua5odGN2I7iUj1PNk83GT4ll wAlg==
X-Gm-Message-State: AMCzsaW0h9W7pl/ctBnoVa3tG+RLsvqGG7l9sKos71bXGw/YNtwVbn5n 5LEZfOBsjMhoa3sjQ3VvCOidPw==
X-Google-Smtp-Source: ABhQp+S3Ti3c0Z8bOr5E619K4Ghek6DUfXrowLEz3XtT004zqqpdiQwtccCJAgMEUFU4tctH5vi6NA==
X-Received: by with SMTP id f90mr226597plf.402.1509412097149; Mon, 30 Oct 2017 18:08:17 -0700 (PDT)
Received: from ?IPv6:2406:e001:3d21:1:28cc:dc4c:9703:6781? ([2406:e001:3d21:1:28cc:dc4c:9703:6781]) by with ESMTPSA id g16sm248506pfd.87.2017. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 30 Oct 2017 18:08:16 -0700 (PDT)
Subject: Re: Updating to RFC6434 to deal with 8200-style header insertion by IPIP
To: Michael Richardson <>, 6man WG <>
References: <> <>
From: Brian E Carpenter <>
Organization: University of Auckland
Message-ID: <>
Date: Tue, 31 Oct 2017 14:08:14 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
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: Tue, 31 Oct 2017 01:08:21 -0000

Hi Michael,

I think this is an interesting topic but I'd really rather
seprate it from 6434bis, because we need 6434bis as soon
as reasonably possible, and this will take a while.

We've got ourselves into trouble at least twice with
automatic tunnels. I'm referring to 6to4 (where I share the
blame) and Teredo. They were both IPv6inIPv4 but I think
some of the same risks will arise with IPv6inIPv6. There may
be contexts where automatic decapsulation is safe and makes
sense. There may be others where it generates either operational
black holes or enticing security loopholes.

So I think this needs to be worked as a separate topic, and
I look forward to your draft... :-)

On 31/10/2017 13:01, Michael Richardson 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)
> 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 <>ca>, Sandelman Software Works
>  -= IPv6 IoT consulting =-
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> Administrative Requests:
> --------------------------------------------------------------------