Re: [v6ops] Operational Implications of IPv6 Packets with Extension Headers - Load Balancer

Tom Herbert <tom@herbertland.com> Mon, 27 July 2020 14:15 UTC

Return-Path: <tom@herbertland.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 BA0D53A19BD for <v6ops@ietfa.amsl.com>; Mon, 27 Jul 2020 07:15:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 4SqB_iRLA8xI for <v6ops@ietfa.amsl.com>; Mon, 27 Jul 2020 07:15:08 -0700 (PDT)
Received: from mail-ed1-x544.google.com (mail-ed1-x544.google.com [IPv6:2a00:1450:4864:20::544]) (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 467CB3A0EB9 for <v6ops@ietf.org>; Mon, 27 Jul 2020 07:15:08 -0700 (PDT)
Received: by mail-ed1-x544.google.com with SMTP id c15so2602988edj.3 for <v6ops@ietf.org>; Mon, 27 Jul 2020 07:15:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=C3aTXNZ8oSfS7c0q5tkE9OuXubDMsdzCDpHwBKKNj70=; b=mK6I4P18kmW0hxnhcXsRTGQDtDfJB9WrI+lSHqP7rXIdqCXUGpejeIyEWATZjLeEME 6SHx9YMyOPj1zh3mekb1lxM8rjUi1gHvZ5FZhGHixi0CrpDbvt5ukd6bGhSeRlqpMRsl ej1vxXkIo8kqfp6kNMPBzTingZvJwO2U/OtspeKiocQ362UEfM9SCD7/VUMRpcu8PJB1 ZjVmMbU2jnuNDwzYsTe0eJgwqhIzdKfSTAifcjO/AunvuF4SkI2u1VQVRKuuLh+MfUJa nWpcl3aVq4m35M6KJYcV2Fh4eEGMCqcWFZX9HgvkUPXXlqHYlwU1ptYKl5G98ZDrre1r ZXfw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=C3aTXNZ8oSfS7c0q5tkE9OuXubDMsdzCDpHwBKKNj70=; b=QC3IVheqk5XiRFNk2AFEoU4KFNC4lHSe3id/A4uDfPG505IQturc+EcAZoYryWnFec m5JRsRzI4vpSFOn0jpCQkha/+o7fn/fw4rIYyasDLBkV84Kk1Ed1ec+FR2o1u7YBGyCM 0n9/wxvxnvYl5MPHAGJCyUFQRK0QTph4nxSljazrCNM84mWbMtZNJgUDurkE0b3Sgqp2 DoGerWESVBjBn6R3shtaar9k1M+xtrbhiuwBoJpHEkEbcc+zwgVPFoOmw57fFzHfT1FD DYLllFVM26NxNImAPrJlX/4zpVi7Y75PLPozFDGSK3tuLGvz6Drm69vHdWqRFDJMjQu4 32qQ==
X-Gm-Message-State: AOAM533xFMviWCk8NKjCiwEE5BVucI4zo+GvhV6Efbq1gZzSaY76twp2 XcsgUH3hZYAWj2H+/0nEkpfkVVfgBk9o3xsBPYj3Cw==
X-Google-Smtp-Source: ABdhPJw4rkklI1tLTH5ESb3aQTWx/Svrshe7C1dNxK4EWhh3ROzaRoQ9adYsgS4U45GOkNVWMU0FfUsVsLhj5pt6ZtM=
X-Received: by 2002:a50:cfc6:: with SMTP id i6mr5612198edk.88.1595859306206; Mon, 27 Jul 2020 07:15:06 -0700 (PDT)
MIME-Version: 1.0
References: <b380408712364589a45ab9f39ab6f764@huawei.com>
In-Reply-To: <b380408712364589a45ab9f39ab6f764@huawei.com>
From: Tom Herbert <tom@herbertland.com>
Date: Mon, 27 Jul 2020 07:14:55 -0700
Message-ID: <CALx6S35rkA5nVPm6C6MToUdHKFmcAabGfMN9prTiUfWr+GKwCA@mail.gmail.com>
To: Vasilenko Eduard <vasilenko.eduard@huawei.com>
Cc: Fernando Gont <fgont@si6networks.com>, IPv6 Operations <v6ops@ietf.org>, "draft-gont-v6ops-ipv6-ehs-packet-drops@ietf.org" <draft-gont-v6ops-ipv6-ehs-packet-drops@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/QofApd5-xCpy48WkDRNtkcd12hQ>
Subject: Re: [v6ops] Operational Implications of IPv6 Packets with Extension Headers - Load Balancer
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: Mon, 27 Jul 2020 14:15:11 -0000

On Mon, Jul 27, 2020 at 2:08 AM Vasilenko Eduard
<vasilenko.eduard@huawei.com> wrote:
>
> Hi Fernando,
> Hence again, following the logic of this draft (the level of detalization that you have given to 5.1) - may be you need additional section 5.1.x: Load Balancer have to look into TCP/UDP ports. Moreover, it could not trust "Flow label" - it is not reliable practice for LB.

Eduard,

What exactly does "not reliable practice for LB" mean.? If this means
that the flow label might change during the flow's lifetime then I
will point out that UDP is equally unreliable for that reason (i.e.
the UDP ports for a QUIC connection can change during the connection's
lifetime). For that matter, a TCP header might be encrypted or in an
encapsulation that the LB doesn't understand so the LB can't access
the TCP ports at all-- in the this case the flow label is actually
more reliable than TCP since it's never encrypted and is purposely
designed to be consumed by intermediate nodes without the need for
expensive DPI.

Tom
> Or alternatively you could say something about LB in section 5.1.2, but because it is a little special case - may be better to have separate 5.1.x
>
> Eduard
> -----Original Message-----
> From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Fernando Gont
> Sent: 26 июля 2020 г. 8:46
> To: IPv6 Operations <v6ops@ietf.org>
> Cc: draft-gont-v6ops-ipv6-ehs-packet-drops@ietf.org
> Subject: [v6ops] Operational Implications of IPv6 Packets with Extension Headers (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-packet-drops-04.txt)
>
> Folks,
>
> We have posted a rev of our IETF I-D "Operational Implications of IPv6 Packets with Extension Headers".
>
> The I-D is available at:
> https://www.ietf.org/internet-drafts/draft-gont-v6ops-ipv6-ehs-packet-drops-04.txt
>
> Your feedback will be appreciated.
>
> Thanks!
>
> Cheers,
> Fernando
>
>
>
>
> -------- Forwarded Message --------
> Subject: New Version Notification for
> draft-gont-v6ops-ipv6-ehs-packet-drops-04.txt
> Date: Sat, 25 Jul 2020 22:28:50 -0700
> From: internet-drafts@ietf.org
> To: Fernando Gont <fgont@si6networks.com>, Gert Doering <gert@space.net>, Geoff Huston <gih@apnic.net>, Warren Kumari <warren@kumari.net>, Nick Hilliard <nick@inex.ie>
>
>
> A new version of I-D, draft-gont-v6ops-ipv6-ehs-packet-drops-04.txt
> has been successfully submitted by Fernando Gont and posted to the IETF repository.
>
> Name:           draft-gont-v6ops-ipv6-ehs-packet-drops
> Revision:       04
> Title:          Operational Implications of IPv6 Packets with Extension Headers
> Document date:  2020-07-25
> Group:          Individual Submission
> Pages:          15
> URL:
> https://www.ietf.org/internet-drafts/draft-gont-v6ops-ipv6-ehs-packet-drops-04.txt
> Status:
> https://datatracker.ietf.org/doc/draft-gont-v6ops-ipv6-ehs-packet-drops/
> Htmlized:
> https://tools.ietf.org/html/draft-gont-v6ops-ipv6-ehs-packet-drops-04
> Htmlized:
> https://datatracker.ietf.org/doc/html/draft-gont-v6ops-ipv6-ehs-packet-drops
> Diff:
> https://www.ietf.org/rfcdiff?url2=draft-gont-v6ops-ipv6-ehs-packet-drops-04
>
> Abstract:
>     This document summarizes the security and operational implications of
>     IPv6 extension headers, and attempts to analyze reasons why packets
>     with IPv6 extension headers may be dropped in the public Internet.
>
>
>
>
> Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.
>
> The IETF Secretariat
>
>
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops