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

Tom Herbert <tom@herbertland.com> Mon, 06 November 2017 18:42 UTC

Return-Path: <tom@herbertland.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C73B13FC62 for <ipv6@ietfa.amsl.com>; Mon, 6 Nov 2017 10:42:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CoR73kdaGtB2 for <ipv6@ietfa.amsl.com>; Mon, 6 Nov 2017 10:42:35 -0800 (PST)
Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1074213FBB4 for <ipv6@ietf.org>; Mon, 6 Nov 2017 10:42:35 -0800 (PST)
Received: by mail-qk0-x236.google.com with SMTP id n5so12166523qke.11 for <ipv6@ietf.org>; Mon, 06 Nov 2017 10:42:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=FuHmHS3gg8tnsFAbm6Sb+MgHRSfPPsRdkUrA5vLMJOk=; b=OdKvo0tnAMBt/R3NS/VAVBRgw3KLnqSXrJB2O08rR5ycrdqVX1YR9H4u22goWAt+JW Jjimka53SZYAJactKo2uQv6Kp4h1yTRp5ZJkbDtn+SPW04Nto4bhU7MtoaAJzVk/xVut A1u1CyGzyU6lg+SWazd5q5fT6rmLqa+ibJlnZPhZfG7u9GuBXyRxJYaO6bcjUCvEThZy ZKJrUbbTh77t5FwfIQtQXRGPeCTV6AnOdAn/FuH2Ne7SJh/xYwBwv6WxnH9Y2+yrq1Cw YK+RWKy6GmUTQ1DC1n0vKINQmLVaeXvuuEmkSFLCB57RrJqTMdnllJ+VsxbLe92wr/ML vX5Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=FuHmHS3gg8tnsFAbm6Sb+MgHRSfPPsRdkUrA5vLMJOk=; b=rJDFdI8fyrU230DX87fwL1XXG6I1mOX4z+dxS38jxNsXBV9AW5j+PWkS+FCkL+jU74 rqsLtHmGJW4h95+MU45S4x8ErNwD7rBck2UBj2pT1lRQo3kFJZNSkWPUFOilwWWIreAj d06hJ7FN2HUj1cuWdgdiTZUSramgSCOnRXY2njZFl80YjiskqCtOWAAyj6Qa1q5MWBUx rSsktjh5IZMaz0+VySlgSxQqb7hHj6V5VNsYrr6Gm8zYWRSMR9V09S2vml/mcPe9Wkru ca5i/vUWjSxEgP+KbSiLz1P0/2RNEUT/iEuV92HKKNv5K659r8vCMf9HL4kpDXWb13xq H7Jg==
X-Gm-Message-State: AJaThX6RwzCGkZgcoeaWkG5/X82gSpGmrsjwbnrqhS08ukdirq1zbR+o 0FF2JdL0/KoFl03jW+CbH0F3eVuzJ754SJDnnA2Y+w==
X-Google-Smtp-Source: ABhQp+TMr8Bh4ZESrCzbxwBDMvSbyw6Wnf7tqMg5OUrPCeJIfQehKutABAgQbK0RyUmckRb/i+Zq4b0UOhb0yi6zeEg=
X-Received: by 10.55.148.70 with SMTP id w67mr23615263qkd.102.1509993303986; Mon, 06 Nov 2017 10:35:03 -0800 (PST)
MIME-Version: 1.0
Received: by 10.237.54.4 with HTTP; Mon, 6 Nov 2017 10:35:03 -0800 (PST)
In-Reply-To: <639c67b05b334853a3fe8f51aa1b84a7@XCH15-06-11.nw.nos.boeing.com>
References: <CAOSSMjUVCSBjbYu3bc7DU+edz2+0+RvU_AMi4FNn2n2075kk9g@mail.gmail.com> <6286.1509408085@obiwan.sandelman.ca> <f9447eb6-fca1-e54c-ff0b-abafa5986960@gmail.com> <25055.1509413008@obiwan.sandelman.ca> <B5488438-0F4B-4362-9B34-6B6FB74D5A49@employees.org> <19111.1509476559@obiwan.sandelman.ca> <37b32942-7d1a-dfd8-288d-ce1f937fc484@gont.com.ar> <CALx6S34d3X_mkq_HTh9H6kMhmS5z6neTGKo37=3--pveSHAArA@mail.gmail.com> <639c67b05b334853a3fe8f51aa1b84a7@XCH15-06-11.nw.nos.boeing.com>
From: Tom Herbert <tom@herbertland.com>
Date: Mon, 6 Nov 2017 10:35:03 -0800
Message-ID: <CALx6S34zyd726bOLUmeAAiH8C8rtRP6XD2645tKj94uPUUCO2Q@mail.gmail.com>
Subject: Re: Updating to RFC6434 to deal with 8200-style header insertion by IPIP
To: "Manfredi, Albert E" <albert.e.manfredi@boeing.com>
Cc: 6man WG <ipv6@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/oZRteNrxSMjnqYdAMhzZY4qhyr4>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 06 Nov 2017 18:42:36 -0000

On Mon, Nov 6, 2017 at 10:04 AM, Manfredi, Albert E
<albert.e.manfredi@boeing.com> wrote:
> -----Original Message-----
> From: ipv6 [mailto:ipv6-bounces@ietf.org] 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?
>
Hi Bert,

The source doesn't need to make that assumption. If it puts something
in a packet that causes an intermediate node to drop it then the
source can detect the packet drop as a signal to back off using the
"advanced feature". This is essentially how happy eyeballs works for
IPv6; if IPv6 packets are being dropped then a host can revert to
using IPv4. A similar method could be used to introduce new EHs. The
key here is that it is only the source that is able detect the failure
and so that would be the one who could modify behavior to work around
the problem.

I agree that ICMP should be sent when packets are dropped due to
protocol, and in fact I wrote draft-herbert-6man-icmp-limits to cover
some common cases where routers drop because of EH limits. However,
ICMP is known to not be reliable and probably not robust enough for
this use case.

>> 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.
>
In that case the destination host can send an error back to the source
host over an application layer protocol.

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

Hosts can certainly be configured as tunnel endpoints, but they don't
perform automatic decapsulation. It would be quite easy to implement,
but I think there are going to be many concerns over the ramifications
if we do that.

Tom