Re: [Int-area] Comments on draft-ietf-intarea-frag-fragile-06

Brian E Carpenter <> Wed, 30 January 2019 20:01 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9864D13133D for <>; Wed, 30 Jan 2019 12:01:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Ciw2gz4VGHqG for <>; Wed, 30 Jan 2019 12:01:06 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::42d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 824E613132E for <>; Wed, 30 Jan 2019 12:01:06 -0800 (PST)
Received: by with SMTP id w73so305077pfk.10 for <>; Wed, 30 Jan 2019 12:01:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=Bl3L2J6Dq71OHxwHUa9SxNYaxgFELN3jHPMrNur2LRY=; b=eiWvtI89A14Hfu+X6JEC4Khf1YpzeghrU+soQZlOdPeJ566TK+u4YYWF4cbWweeCq2 hUsZKoiE1+kM3HI/CZa1qJu+jirE7ukqPW8WZlX+eJQGdvrL0FUA4DdepqlDnqWr0+Q/ f9hl2n19B5OPo91yD/BZYx5nb0ua9gevc8J88u7vMewFumpv5kuflGfke7rkDaoByXm1 UKovOTjFHOhF4a3z3HP0PfK4M8FfpTTvT6gKmuSw5NlJ75+aFqqJOXd2HSQJ1RkGJTad PXs05a3rPKrhHwJWos/4hIxw9orGqTo2d4Twbjz3CH6gncFXMqgjEmCsf9Tx2qFvjsBw ESGA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=Bl3L2J6Dq71OHxwHUa9SxNYaxgFELN3jHPMrNur2LRY=; b=YkDO5j3CawOKrkelbZQfv+bKbh2gqzWxlofzo3NKaAR+G2czbkbzPoEV1jpBpVo1f7 gPtcGSKMEL8fLx3VflM4uUTc2ekZ7U+7vxktLL1RHwgd2Lz2Xl2Z2ChvzJj229ipKCQR VrM1ReEl4YefU3lMLt5xaioDW1C8g8pI05MgSsBsEWffcO15ImLdIeg5JhmyxnY0d/Dl NjR4ELMkw28NphNOm94/WqBS4HbN+s1QoWcVn3z0MJYvFNQu3UhPPr1cNvmxb9Y7osaa /Dg4CYn8RG6su2OoUHGz+MRSksGuYpObZJ5c+V8o9dwGPKz1eHCB8nzUXH24pTNk6NjR DPpA==
X-Gm-Message-State: AJcUukdRZqnttaI/Lf+Vt1+ggmcfFtiip2udprZ7pO/Se54R/IszOIAF YYa8DRIvCfjk4czz9Fkw/LbpKtig
X-Google-Smtp-Source: ALg8bN7tGXco7nr3ugbs9BwHO16C9pigqsXDs2oSIKP5WbQEuN6zn9fPs8aIItp7Q8CUcKOoD6UPWg==
X-Received: by 2002:a63:31cc:: with SMTP id x195mr29035701pgx.52.1548878465570; Wed, 30 Jan 2019 12:01:05 -0800 (PST)
Received: from [] ([]) by with ESMTPSA id r66sm3871215pfk.157.2019. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 30 Jan 2019 12:01:04 -0800 (PST)
To: Stewart Bryant <>, Fred Baker <>, Tom Herbert <>
Cc: int-area <>
References: <> <> <>
From: Brian E Carpenter <>
Message-ID: <>
Date: Thu, 31 Jan 2019 09:00:57 +1300
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <>
Subject: Re: [Int-area] Comments on draft-ietf-intarea-frag-fragile-06
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF Internet Area Mailing List <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 30 Jan 2019 20:01:14 -0000

On 2019-01-31 03:13, Stewart Bryant wrote:

>>> Add to section 7.3:
>>> "Routers SHOULD use IPv6 flow label for ECMP routing as described in [RFC6438]."
> If we want to migrate to the FL then we really need to state that the FL MUST be set by the sender. Without, that we are never going to wean routers off looking at the five tuple, if indeed we ever succeed in doing that.

I would have loved to make it a MUST in RFC6437 but that wasn't the consensus, so it's a SHOULD, confirmed this very day by RFC8504 (

As I said the other day, if and only if the flow label is non-zero, the {source, destination, flow_label} tuple is a fine thing for a load balancer to use. If the flow label is zero, you need to fall back to the 5-tuple, which is broken for fragmented packets as we know. So for IPv6 packets with a zero flow label and a fragmentation header, you have no choice but the {source, destination} tuple.

However, that is a much better picture than for IPv4.