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

"Manfredi, Albert E" <> Mon, 06 November 2017 18:05 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6841013FBBD for <>; Mon, 6 Nov 2017 10:05:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 379c7dd4eWUU for <>; Mon, 6 Nov 2017 10:04:58 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B3DFC13FB81 for <>; Mon, 6 Nov 2017 10:04:58 -0800 (PST)
Received: from localhost (localhost []) by (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id vA6I4wHx025245; Mon, 6 Nov 2017 11:04:58 -0700
Received: from ( []) by (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id vA6I4lNQ024801 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Mon, 6 Nov 2017 11:04:47 -0700
Received: from (2002:8988:efdc::8988:efdc) by (2002:8988:efdb::8988:efdb) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Mon, 6 Nov 2017 10:04:46 -0800
Received: from ([]) by ([]) with mapi id 15.00.1320.000; Mon, 6 Nov 2017 10:04:47 -0800
From: "Manfredi, Albert E" <>
To: Tom Herbert <>
CC: 6man WG <>
Subject: RE: Updating to RFC6434 to deal with 8200-style header insertion by IPIP
Thread-Topic: Updating to RFC6434 to deal with 8200-style header insertion by IPIP
Thread-Index: AQHTVxp+zYH5bQ3/lEaBRWQjFVo6IKMIGViA//+H4wA=
Date: Mon, 6 Nov 2017 18:04:47 +0000
Message-ID: <>
References: <> <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-TM-AS-MML: disable
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 18:05:00 -0000

-----Original Message-----
From: ipv6 [] On Behalf Of Tom Herbert

> 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).

Interesting thread. My question has been, during this exchange, why should we expect that *any* given payload should be assumed ahead of time, by a source, to be acceptable to a destination? Or if not acceptable, to return a particular ICMP message?

> 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.

Yes. And if the source sends some obscure spreadsheet or word processor format, or streaming media compression algorithm, there's no assumption that the obscure format will be acceptable either.

> 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.

As in many other examples of not-very-standard payloads? Is there an expectation that any random host out there should know to be the egress of a tunnel? Or is this the sort of job one expects only or mainly from certain routers, very deliberately configured for such a task?