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:13 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 D78193A0895 for <v6ops@ietfa.amsl.com>; Wed, 29 Jul 2020 03:13:21 -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 6OtPwqZwWkZu for <v6ops@ietfa.amsl.com>; Wed, 29 Jul 2020 03:13:19 -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 6B21C3A07D1 for <v6ops@ietf.org>; Wed, 29 Jul 2020 03:13:19 -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 58F2D280A14; Wed, 29 Jul 2020 10:13:15 +0000 (UTC)
To: Vasilenko Eduard <vasilenko.eduard@huawei.com>, IPv6 Operations <v6ops@ietf.org>
References: <d8d59ce07f7f4031a545ff6e24fdbb88@huawei.com>
From: Fernando Gont <fgont@si6networks.com>
Message-ID: <dcf506e1-9305-4f44-82b8-fa18e42645d9@si6networks.com>
Date: Wed, 29 Jul 2020 07:12:13 -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: <d8d59ce07f7f4031a545ff6e24fdbb88@huawei.com>
Content-Type: text/plain; charset=koi8-r; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/P1Cubqf2wzGpawt_Vqkry6Bejk4>
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:13:28 -0000

On 29/7/20 05:26, Vasilenko Eduard wrote:
> Hi Fernando,
> IETF has many WGs that developing now many new EHs. iOAM, iFit, SRv6, AltMarking, APN6, and many others.
> Do you believe that it would increase IPv6 drop rate in midterm?

All the measures that we have so far done seem to indicate that the use 
of IPv6 EHs greatly increase the packet drop rate when traversing the 
public Internet.

You may be able to employ EHs within the so called "controlled domains", 
though.


> I do assume that you do not want to make any comment in the draft, because it is "speculation" (or "prediction"?).

What we are trying to do with this document is to report and elaborate 
on the current situation, more than trying to guess what might happen in 
the future.


> I am asking, because may be the question: what to do to mitigate anticipated problem?

My understanding is that technologies such as SRv6 are to be employed in 
controlled domains. In such cases, either you control your network or 
you cooperate with the folks controlling the network -- so you shoudl be 
fine (or should be able to be fine).

OTOH, you are not that lucky when sending packets on the public Internet.

To a large extent, the drops have to do with boxes not being able to do 
their work when packets contain EHs. So most likely the problem would 
how away if/when such boxes are replaced and if they are replaced that 
are able to handle packets with EHs more gracefully. So, that's 
functionality that vendors are not willing to provide for free, and 
operators are not willing to pay extra for. So the future doesn't look 
very promising in this respect... -- but you never know.

But certainly, if there's any improvement in this respect, it will grow 
out of widespread awareness about the problem is question.

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