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

Ole Troan <otroan@employees.org> Tue, 31 October 2017 08:30 UTC

Return-Path: <otroan@employees.org>
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 CA4F413F6B7 for <ipv6@ietfa.amsl.com>; Tue, 31 Oct 2017 01:30:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 jJjurGn4nRnB for <ipv6@ietfa.amsl.com>; Tue, 31 Oct 2017 01:30:07 -0700 (PDT)
Received: from accordion.employees.org (accordion.employees.org [198.137.202.74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D55913F6B9 for <ipv6@ietf.org>; Tue, 31 Oct 2017 01:30:06 -0700 (PDT)
Received: from h.hanazo.no (219.103.92.62.static.cust.telenor.com [62.92.103.219]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by accordion.employees.org (Postfix) with ESMTPSA id 67FD82D50BC; Tue, 31 Oct 2017 08:30:06 +0000 (UTC)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 96C67200823210; Tue, 31 Oct 2017 09:30:04 +0100 (CET)
From: Ole Troan <otroan@employees.org>
Message-Id: <B5488438-0F4B-4362-9B34-6B6FB74D5A49@employees.org>
Content-Type: multipart/signed; boundary="Apple-Mail=_DE934B9D-050A-4557-ADEC-A07C98978884"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 11.0 \(3445.1.7\))
Subject: Re: Updating to RFC6434 to deal with 8200-style header insertion by IPIP
Date: Tue, 31 Oct 2017 09:30:03 +0100
In-Reply-To: <25055.1509413008@obiwan.sandelman.ca>
Cc: Brian E Carpenter <brian.e.carpenter@gmail.com>, 6man WG <ipv6@ietf.org>
To: Michael Richardson <mcr+ietf@sandelman.ca>
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>
X-Mailer: Apple Mail (2.3445.1.7)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/o_IKgM6TIfsWY-O4RROrk7QOmi4>
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 08:30:09 -0000

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