Re: [v6ops] Operational Implications of IPv6 Packets with Extension Headers - implications from new development for EHs

Fernando Gont <fgont@si6networks.com> Wed, 29 July 2020 10:28 UTC

Return-Path: <fgont@si6networks.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17B223A0887 for <v6ops@ietfa.amsl.com>; Wed, 29 Jul 2020 03:28:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=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 u9vEUm_mV4XR for <v6ops@ietfa.amsl.com>; Wed, 29 Jul 2020 03:28:28 -0700 (PDT)
Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C1F23A08FF for <v6ops@ietf.org>; Wed, 29 Jul 2020 03:28:27 -0700 (PDT)
Received: from [IPv6:2800:810:464:1f7:8ca5:7f63:e5ff:a34] (unknown [IPv6:2800:810:464:1f7:8ca5:7f63:e5ff:a34]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id EA0CC280BFD; Wed, 29 Jul 2020 10:28:24 +0000 (UTC)
To: otroan@employees.org, Gert Doering <gert@space.net>
Cc: Vasilenko Eduard <vasilenko.eduard@huawei.com>, IPv6 Operations <v6ops@ietf.org>
References: <d8d59ce07f7f4031a545ff6e24fdbb88@huawei.com> <20200729084351.GG2485@Space.Net> <32BAEAEA-7352-4BAE-ADA8-FDA2395D5732@employees.org>
From: Fernando Gont <fgont@si6networks.com>
Message-ID: <a6ed89a8-c12e-b8d2-c720-5cc02e127a68@si6networks.com>
Date: Wed, 29 Jul 2020 07:28:06 -0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <32BAEAEA-7352-4BAE-ADA8-FDA2395D5732@employees.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/sw8y0SUUgw8YhmyvNRZmvOQ-DnA>
Subject: Re: [v6ops] Operational Implications of IPv6 Packets with Extension Headers - implications from new development for EHs
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 29 Jul 2020 10:28:36 -0000

On 29/7/20 07:13, otroan@employees.org wrote:
>>> I am asking, because may be the question: what to do to mitigate anticipated problem?
>>
>> Do not assume EHs will work outside a very well-defined scope (SRv6
>> is an example of "will work, because won't leave the network where
>> needed").  If you start work with the goal "must work across the
>> wild Internet", abandon the idea to do this with EH.
> 
> Is that significantly different from:
> 
> "Do not assume ICMP, IP fragments, or any other transport protocol than TCP port 80,443 or UDP port 53 will work. Do not assume anything but IPv4 will work."

The difference is that modulo fragments, non of those prevent boxes from 
doing their work. -- they may still be filtered, but folks don't 
necessarily have to resort to that.



> I think the EHs suffer a bit from a chicken and egg problem.
> That is, if a cross the Internet EH ever got defined, then networks would adopt to carry it transparently.

There is indeed quite a bit of a "chicken and egg" problem here (*). But 
it's not simply an arbirtrary filtering policy, but rather the result of 
packet handling constraints.


(*) There *are* cross-Internet EHs: ESP. But it suffers from the same 
problem -- so, ironically, you may need to encapsulate or do something else.

Quite recently, I migrated a few IPv6-over-IPv4 tunnels I had to 
IPv6-over-IPv6. BUt things wouldn't work. After some debugging, it 
turned out that the "tunnel encapsulation limit" option was being 
automatically employs for v6 tunnels, which caused the resulting packets 
to be dropped. Of course, the workaround was to disable it.



> I didn't see if this draft got into localising where the breakage happens; at least previous wisdom was that it happened at the edges not in the core.

RFC7872 suggests that it happens both at the edge and at the core.



> Anyway I don't quite understand what this document adds to work describing ossification in general

Avoiding rehashing the same discussion everytime the issue of EHs comes up?



> and the previous work on operational considerations for EHs.

What's the "previous work on operational considerations for EHs"?

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492