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

Mark Smith <> Wed, 01 November 2017 01:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1525513F5B9 for <>; Tue, 31 Oct 2017 18:29:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.496
X-Spam-Status: No, score=-1.496 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, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id f74RirXNIwhT for <>; Tue, 31 Oct 2017 18:29:24 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400c:c08::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E665713F586 for <>; Tue, 31 Oct 2017 18:29:23 -0700 (PDT)
Received: by with SMTP id n22so565299uaj.13 for <>; Tue, 31 Oct 2017 18:29:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=SRkML/hOu68kbcCnFYlG3tK/muE/7i6MtDqqgmqak/c=; b=n34S4jDI5fPPA9EpHfPyNYvNC6RoiXTQLRto5/+Zp9JEHLncQsPa25nR+8+CNasLaC G/h5G0zYUUA8BLQ1ZUBF7jee/WJOpVz3GFYRthB++cJHoO4sEMqkLvAnNl3hBVGg1uQ5 00cfbDJ+AXYu2FSRegk40IdFDLkhlkgM1d+88+R5bpNdNWNjK1iBwyQPmzbP1ZAx3oO9 ImS18YiDiDMPPnLCyBFW2kLKRKm2LtADNbMMkD4PPoWjTQVH2OT14X7F7USKTl28Vf+k 58IWBjPRJXv3pGhb2JURUDInjXyMgH15hsYJJzH+2EHoM9gr2EW9qwoDFIXYLEmSlzii CG1A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=SRkML/hOu68kbcCnFYlG3tK/muE/7i6MtDqqgmqak/c=; b=MtKnhaPMOiE6Km0vkESLP9eaD1Jzu7JvhxY26PrY0WlWJbjJaqRcGxXCiG8TP8SlJ2 X0PtY6hp75qOpX/2wHBgJRGmRV/iw4HTMWtQWVVALXFxNFkHYHmD3PX67RLeEX7Vvt5J TY8vpQgoOQ9+GlFBE4zmFfB5sFE9Uxu0XFhYqs3JLwp/yhMJ5ywYVEzfeFy9nzhNAUp5 3GvFDm82DceKjsXb1yNUQQRubFUTJU8qKO9VFpsGepSmfUnLAlw3a6O95Tks5dli0Pa5 ACo+iE8WdjAFWCBhtdtP7r6vEvdBsa/yw6nd4EMx68ql8FXLN8GoIiPRxoh+JoTj81hp XI6w==
X-Gm-Message-State: AMCzsaUH0m/W7KypWAMMBWvq2U5anGba3FzTN8oXxpdOO/mRWuHkYecc eQkiQvl4AvuK1+z6kBf07LmAFkMGE2Tr0/61h7g=
X-Google-Smtp-Source: ABhQp+TpmyDbrAzER9XPJHJiUanHlCKAwQbyHHH/xE0Kiyab9H1wcBcgFwySMXXCnb1W/bhv3cBJrELwcUC5F60NYf8=
X-Received: by with SMTP id q15mr3257653uae.120.1509499762840; Tue, 31 Oct 2017 18:29:22 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Tue, 31 Oct 2017 18:29:22 -0700 (PDT)
Received: by with HTTP; Tue, 31 Oct 2017 18:29:22 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <>
From: Mark Smith <>
Date: Wed, 1 Nov 2017 12:29:22 +1100
Message-ID: <>
Subject: Re: Updating to RFC6434 to deal with 8200-style header insertion by IPIP
To: Michael Richardson <>
Cc: 6man WG <>
Content-Type: multipart/alternative; boundary="f403045f6d2c271848055ce1cd4d"
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 01:29:26 -0000

On 1 Nov. 2017 06:03, "Michael Richardson" <> wrote:

Ole Troan <> wrote:
    > Without having thought very much about it... I do think requiring a
    > host to accept tunnelled packets to itself by default or not, requires
    > further considerations.

I agree: it requires further consideration.

    > I am aware of no implementation that would support this. I would also
    > be worried about this opening the door for "alternate" paths into the
    > host stack.

I agree. Nobody does it this way.
Yet 8200 (and 2460 before it) says that this is the way to insert headers.

I think we need to be clear about what is "inserting" is. To me, the word
"inserting" means inserting to into something that already exists and has
previously been created - cut apart, insert, glue back together.

IPinIP in the network is not doing insertion. It is adding by encapsulating
with a new IP header. That's the way we add information at all other layers
of the stack.

IPinIP in a host is, for some reason or other, not encoding all of the
information in the first IP header, so it adds another one to carry it.
IPsec tunnel mode would be an example.

IPsec transport mode isn't "inserting" either. The host sending the IPsec
transport mode packet builds the entire thing, and adds the AH/ESP header
at the appropriate time during the encapsulation process as the IPsec
packet is built before being put on the wire.

So truly "inserting" (cut, insert, glue) into an existing packet is not
something that has been part of any IETF protocol as far as I'm aware.


One of 6463 or 2460/8200 must be wrong.

Essentially 8200 says to do something that doesn't work.
Should we be at all surprised that there is was much push to do it a
different way?

If we don't fix 6434 to make it work, then our hard fought compromise in
is moot.

ps: I'm not advocating for changing 8200.

Michael Richardson <>ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-

IETF IPv6 working group mailing list
Administrative Requests: