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

Erik Kline <ek@google.com> Tue, 31 October 2017 09:15 UTC

Return-Path: <ek@google.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 BBD9013F5D7 for <ipv6@ietfa.amsl.com>; Tue, 31 Oct 2017 02:15:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level:
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 h0I99bUzqAWS for <ipv6@ietfa.amsl.com>; Tue, 31 Oct 2017 02:15:25 -0700 (PDT)
Received: from mail-yw0-x229.google.com (mail-yw0-x229.google.com [IPv6:2607:f8b0:4002:c05::229]) (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 209C413F621 for <ipv6@ietf.org>; Tue, 31 Oct 2017 02:15:25 -0700 (PDT)
Received: by mail-yw0-x229.google.com with SMTP id l32so14088493ywh.13 for <ipv6@ietf.org>; Tue, 31 Oct 2017 02:15:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=nOXyC+7/gBssmWGF+tzFl4pQuPTDqZdJ4f78RO2Zvto=; b=kSt8fcgDIKUvoK7FQnR1IgMT82LbNhA3KgO75cCdiCME2tPzmnf5mKffi3C/6s76OS q+IMgz0ROPmiFt58oAbpv4epl7mAsHG3MKGkU0Dh9gYVXflTOb1iu8j/76RPlji6Pv4S nk8ObScUrzKQhoHyieAG4xqTUWjGtKLTmWc5HT2/PzpGbRFsEBuvT1rkhosyvtCaZwYL JIk9HGr2MPSSc7hYFv053bdDt8oblS9Uqr4G4PBua0VzPWsklgUAHGcySdb3RrOT2O3g n5L4wRaTQNvqtXbxaMFklgwUgEUId5W1NFj7pWWPV8WiQOK3Ha7r8THNXi876YrdFLMW FJ+g==
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; bh=nOXyC+7/gBssmWGF+tzFl4pQuPTDqZdJ4f78RO2Zvto=; b=DSlJfUb0hjgIuYQJbDKFdWt/ujste6qtcrmjBGC36yyhm5flETNfEwNrK4AOHojb6j exD12Lht6hNE1Jr9A0nu3iU0oP6nsQZ3QyJqlyeiiY4o0iU2a5kQSIGBwmcwO3+M3wIr vTtz+Z4bW0grVIgak/LgTzWXDGfReKjOfYkA+8q4zGQQTPFWrnIHhwH7Di2st54rQA6U ulzQeGU59/H1JBf2UXu5b3dFiCKZVpU3P/+czh+36a8hjWNB13PaZrAalhiZMQZGxPvA TaavV/XM7it4z1UwmAl49VryCf5T/KsNbFKjEKoYTRncGhgImhu7xZKRem/CZi/qd8aT NW+A==
X-Gm-Message-State: AMCzsaWz+uekgMS1gcSLrf7bgjFJuzmcl0+vh1lctXWlo1qfL8wf/rKc QljtCJhVqwfj1oejVRuWcMOWTY8VRRKGTOO97QNMwA==
X-Google-Smtp-Source: ABhQp+Qux0MZ5SaRbuQSNJAqBBbKleJIQ+yqMi7I08N5CTGCChMqrTXZ7AEe7VpcaRUxEWHEyyUPl84xa1NnMWLyueU=
X-Received: by 10.37.186.203 with SMTP id a11mr704187ybk.460.1509441323913; Tue, 31 Oct 2017 02:15:23 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.37.14.196 with HTTP; Tue, 31 Oct 2017 02:15:03 -0700 (PDT)
In-Reply-To: <B5488438-0F4B-4362-9B34-6B6FB74D5A49@employees.org>
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>
From: Erik Kline <ek@google.com>
Date: Tue, 31 Oct 2017 18:15:03 +0900
Message-ID: <CAAedzxruO-iKUBej_6HxtpHxBNEgK_xaMJsVtmsTwXypj3+Z_A@mail.gmail.com>
Subject: Re: Updating to RFC6434 to deal with 8200-style header insertion by IPIP
To: Ole Troan <otroan@employees.org>
Cc: Michael Richardson <mcr+ietf@sandelman.ca>, 6man WG <ipv6@ietf.org>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="f403043deec8f5d2df055cd431fe"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/MLZh1M99PDWFkjT5pri9TzYOc7M>
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: Tue, 31 Oct 2017 09:15:28 -0000

This would certainly complicate tracking ingress interface and
applying rules that require ingress interface information to apply
correctly.

Blech.

On 31 October 2017 at 17:30, Ole Troan <otroan@employees.org>; wrote:
> Michael,
>
> 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 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 think you would have to write a draft.
>
> Another aspect of IP in IP is that with the recent troubles we have with doing path MTU discovery and fragmentation at the Internet layer, that might not be the optimal encapsulation for tunnelling anymore.
>
> Best regards,
> Ole
>
>> On 31 Oct 2017, at 02:23, Michael Richardson <mcr+ietf@sandelman.ca>; wrote:
>>
>>
>> Brian E Carpenter <brian.e.carpenter@gmail.com>; wrote:
>>> 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.
>>
>> Well, I tried to raise this while doing 8200, and was told that I should wait
>> until we got to host requirements.
>>
>> I'm inclined to file an errata against 8200 if 6463bis proceeds without
>> dealing with the issue.
>>
>>> 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... :-)
>>
>> I can write a draft.
>> I will write it to update 6463.
>>
>> --
>> Michael Richardson <mcr+IETF@sandelman.ca>;, Sandelman Software Works
>> -= IPv6 IoT consulting =-
>>
>>
>>
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> ipv6@ietf.org
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>