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

Tom Herbert <> Mon, 06 November 2017 17:00 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2E8BE13F584 for <>; Mon, 6 Nov 2017 09:00:21 -0800 (PST)
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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] 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 mkdV-IYG3FA8 for <>; Mon, 6 Nov 2017 09:00:19 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400d:c0d::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 355EB13FAF7 for <>; Mon, 6 Nov 2017 09:00:19 -0800 (PST)
Received: by with SMTP id p1so11793839qtg.2 for <>; Mon, 06 Nov 2017 09:00:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=M8VINWRTaxug6UU9U9/Sw2/FnPGznrXq416ZuYY0RjY=; b=ryKez6YIWLkzhDBEwCwFFF379WW0awfkOw6/khfltszPPfuG+d0VMvaGLExhORSo0b w99flSOFskLXgnviVEZ3vxnbI8dB25rKjP9I4DtD2Sh5VW22FMsxbdjFaKrpzhceeqHD t5NEV2HtmmYd2adUgG57FVyp5UtrJJagAas0AR880nRnFLIj1QT3EclTGgan17nVyvrF FHVfgAaAmPjk5LJqR3VzmoCLnxOeM3mEVAjUR7lswb8tfvKdGsyZNQRajx8JTLAkPRVi 1O6C5K0llpELQCOeWqIzZTbXBf/gQaB/3MPNauphc9KzM9F5O7/NL+WEl1Q5nolTlEn5 bBfQ==
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=M8VINWRTaxug6UU9U9/Sw2/FnPGznrXq416ZuYY0RjY=; b=NiOukHPBlpwUdpCPsGNKsPZ5twEw0So+CZlA9JqYcZdVIUrPJ/nKSi1tihjN42SqjC 0efAh63vOP5q84T8dFOm/b5vyzJxhMysuEsmr8Sx3o/M+E1vTDO5e2KV6AEXWcW9Hqlh OpwJ5tSoL8O4lDrETk1X85SvB99WivycKD5zKtH0wObp0fNh2e7kw8+gYnaUWXcd0yXu g+P4meFsY4cQQdGDchSGiM/0d1VJbcll3KRaVYuZ4JOYNK4+BfHoTNxXRfVDgio48KeM awb0j2IeqeizCi8JrnS+9DPZRvn+1zP4/PAe7uV7rOK95mYm7R5Eb9Q0R5QifV56iZHB 9f3A==
X-Gm-Message-State: AMCzsaWoOT4C7n0PSMc5my85cjMFO+8txTIvLPT4ez75CSSxr60/T+yF yh5rZD++jUqgMCw0wBkhN5ZkvkGNx3D/Vs7TOUXkZg==
X-Google-Smtp-Source: ABhQp+QPw8HjmIdACazSwNZJy0EOi85+cZPKuWtyfKucIatMBdryJ3DAfAK3wvXf/2seTZFnTdEdRb4Lly+TI9+qPTg=
X-Received: by with SMTP id p34mr24284605qtb.27.1509987618155; Mon, 06 Nov 2017 09:00:18 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Mon, 6 Nov 2017 09:00:17 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <> <> <>
From: Tom Herbert <>
Date: Mon, 6 Nov 2017 09:00:17 -0800
Message-ID: <>
Subject: Re: Updating to RFC6434 to deal with 8200-style header insertion by IPIP
To: Fernando Gont <>
Cc: Michael Richardson <>, 6man WG <>
Content-Type: text/plain; charset="UTF-8"
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: Mon, 06 Nov 2017 17:00:21 -0000

On Mon, Nov 6, 2017 at 8:15 AM, Fernando Gont <> wrote:
> On 10/31/2017 04:02 PM, 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.
> No. EHs are not inserted or removed. When you do IPinIP, you are
> creating a brad-new packet, *not* inserting EHs in the existing packet.
I agree.

I think the sticking point is going whether a node can blindly perform
IP-IP encapsulation on packets to arbitrary destinations (as opposed
to using IP-IP for explicitly tunneling across a network). This
requires the assumption that all nodes in the downstream path will
forward a packet with IP-IP and the added extension headers, and that
the destination will accept such packets. The problem is that if a
packet is dropped because of the encapsulation or EHs and no ICMP
error is returned to the encapsulator then there is no way to recover.
The original source host might see packets being dropped on a
connection but will have no idea why. The encapsulator sees no problem
and so it won't modify its behavior.