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

Tim Chown <tjc.ietf@gmail.com> Wed, 29 July 2020 07:31 UTC

Return-Path: <tjc.ietf@gmail.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 E4A2F3A0D3A; Wed, 29 Jul 2020 00:31:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 REQVKfNjZxY2; Wed, 29 Jul 2020 00:31:47 -0700 (PDT)
Received: from mail-wm1-x335.google.com (mail-wm1-x335.google.com [IPv6:2a00:1450:4864:20::335]) (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 877C73A0D32; Wed, 29 Jul 2020 00:31:47 -0700 (PDT)
Received: by mail-wm1-x335.google.com with SMTP id q76so696966wme.4; Wed, 29 Jul 2020 00:31:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=vv/beJj8MfZaj0e/iPp8WSkobgJrj3loHRYgbnqu9QY=; b=hgCWZWHE1pn5Zs+FjJLLYkXRij/sXrzazH2iu+QlPXYjXHt1HxX1zDW1ZdIaeXVdS5 T4d3j/nfcc41WuF4jR/XKdqeTaSI+QAx5VWcG223QtUp+FN2YMaBHfIPgm8pj7Vpuvg7 9VkMHLMlwKC1+ZwvHvbb9yoO02fr4sWIW1wPUurF7lj1WKLW+9siUruALWEwRggcWK4I 6eKZM1SDDVUiQ4jTwjT+joyTid+BaozaNtwe6oUMpIWzP2hJ21R5Bhpu73r8UbK96Dv4 L3sFD3euaMEreW8NitVfJvfPBeEFa5mXenvoyWUyyvp8EXTGXMP9EwT0TI25pr2RggMw gSpA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=vv/beJj8MfZaj0e/iPp8WSkobgJrj3loHRYgbnqu9QY=; b=Uuv7KxTgai0aPwNBvVGy/AO1LV706ifH5QnvmSmZWAbXYYPmD49w1TQ0RVWyiWkgAH TZLOd57fRwqP0CRhqIePdAFEAGU/YfIr8FpruVvvC+7QwNecEw6vtshQHcBG2UdAxLW9 cLeC60L6QzP7F3Dza8DzGmY9RiWb1C0wUbogWGm/a+QjKTOTQyoLmOV50RGV6R0jJfb8 vRdi2ltQQ2ocziG59rJmCL3Ocana2KiLAI10qyErBfsQD/VX+yrKU/v2IajLIALyTEpt vvmKpKSx8Hvh7R0pU0r+OUYmIB0EBoEYBpYtoVXXxZlqxuehlI7Og0s0AmDfHS2awyo+ /R7Q==
X-Gm-Message-State: AOAM533B+M4HYYPm3uoCaK67fTOzx5yQKaRJW5zct7CdU5c7auzCdtnc 9xm4FMYg1DnCqR7EPHCLSKY=
X-Google-Smtp-Source: ABdhPJzokGRgghpTuwowcwrDes/l71hyQIU0RoBOGVnKTSE8x6hjGc0jUkkOD6Jb3NwE7QOtzDJDgQ==
X-Received: by 2002:a05:600c:25cc:: with SMTP id 12mr7264209wml.120.1596007905929; Wed, 29 Jul 2020 00:31:45 -0700 (PDT)
Received: from [192.168.0.21] (tchowndsl.claranet.co.uk. [212.188.254.49]) by smtp.gmail.com with ESMTPSA id t14sm3801230wrg.38.2020.07.29.00.31.44 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 29 Jul 2020 00:31:45 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
From: Tim Chown <tjc.ietf@gmail.com>
In-Reply-To: <32d99263-7176-3188-b9d2-72a67c6ed3d6@gmail.com>
Date: Wed, 29 Jul 2020 08:31:44 +0100
Cc: Fernando Gont <fgont@si6networks.com>, Tom Herbert <tom@herbertland.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-Transfer-Encoding: quoted-printable
Message-Id: <1938CB5B-B2CD-43DC-A24D-CE75BD56941E@gmail.com>
References: <b380408712364589a45ab9f39ab6f764@huawei.com> <CALx6S35rkA5nVPm6C6MToUdHKFmcAabGfMN9prTiUfWr+GKwCA@mail.gmail.com> <6439ceb9d73b435d950e73a7a2d68fc7@huawei.com> <CALx6S37ih8VabN2PHvQ3ELDvV2DoiUqnd28LRxr4ofj6zUq3Jw@mail.gmail.com> <947a50398cbb4bbcad85462a69d7dd45@huawei.com> <CALx6S35FX-SNoNFhd2JXFio9B0vGVyXGkeob=7x+dn6u4qOaVw@mail.gmail.com> <42B3046E-6157-4460-A10B-F13E299340B6@apnic.net> <4720fdaa-71b6-4816-e800-938c01a30abb@gmail.com> <CALx6S342x_u4pLD5DpYKh=_u1e0dLujgrmoxfKpeuE5SbZerEA@mail.gmail.com> <d6cc0f77-151f-060f-54f0-2987597ff11f@si6networks.com> <32d99263-7176-3188-b9d2-72a67c6ed3d6@gmail.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/KpDGwZZg5dVJo1Lc_FfMk_taBnU>
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: Wed, 29 Jul 2020 07:31:49 -0000


> On 29 Jul 2020, at 05:03, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
> 
> <snip>
> 
> All we can do here is write documents. So if
> the consensus is still what the standards track documents say, including
> Node Requirements, we have actually done our duty. And we have, in RFC8504:
> "All nodes SHOULD support the setting and use of the IPv6 Flow Label
> field as defined in the IPv6 Flow Label specification [RFC6437].
> Forwarding nodes such as routers and load distributors MUST NOT
> depend only on Flow Label values being uniformly distributed.  It is
> RECOMMENDED that source hosts support the flow label by setting the
> Flow Label field for all packets of a given flow to the same value
> chosen from an approximation to a discrete uniform distribution."
> 
> After that it really is up to vendors and operators to do what is best
> for them. If it takes ten years for all products to meet the Node
> Requirements, so be it.

Worth noting that RFC8504 is the third iteration of the IPv6 node requirements document, and what it says may and does change, partly as new RFCs are published, partly with more operational experience.

That said, the text above about flow label usage is the same in RFC8504 as it was in RFC6434, so the guidance has been the same for at least ten years or so.  The flow label wasn’t explicitly mentioned in the first node requirements document, RFC4294.

Tim