Re: [Tsv-art] [v6ops] [Last-Call] Tsvart last call review of draft-ietf-v6ops-ipv6-ehs-packet-drops-05

Tom Herbert <> Thu, 08 April 2021 14:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 76C1F3A195A for <>; Thu, 8 Apr 2021 07:21:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.897
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=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id cH-DHNqLhXtD for <>; Thu, 8 Apr 2021 07:21:30 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::52e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 85B4B3A1955 for <>; Thu, 8 Apr 2021 07:21:30 -0700 (PDT)
Received: by with SMTP id m3so2655812edv.5 for <>; Thu, 08 Apr 2021 07:21:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=6Nn0UFMMR4Qk6z7HvYHywXw8SceXx/5qizEENQlqnZo=; b=F2uJN58ESxyR9nilDiIisbIs1gvVHNHHq32JVkvH5MjvCa1SP2m5qXaoS1KXI/2dfz FQJlO0F9feg6xmKnuR0gZAjIhx0iDY4k0m+Hf9o+sqpI692SGpQXT+hDzBdnUgoPBdfA bR4HwP7mCSWHiZGAK0g3/hhm+VuUCIPkPwOzy5H8Ivcf7+i2Yai6uixXzdJNAtcbshOM ov8bfg5vJ294bIpnehUuX6pLZK8PIrgH7BLZHTl3oKed+vllISrFP9OA63stGJP5XHre VE1kS5sw1ZfYKiY7HOSvrcrw3NBqNjHBsFPHmItOZNyAfZ56opLTaBhZaZEk8XbmrIm1 /gxw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=6Nn0UFMMR4Qk6z7HvYHywXw8SceXx/5qizEENQlqnZo=; b=T6w0omNQHBfU/9P4uwpsnjUQ8QX01wfN8O7sYN4qFdkWQnrGmVkq7LW820aQTjYCHA j82+cUVG9vA/1zumHbJbRcF2J7q9/YIwTft74YBK3PB9eSVMOMKQ1TViKzxF2uqIySF1 0CQc7scVeNmQpkmkGJnzSwns4KWw3Z3dboT2NuIJXrm3SGlOOd1iqSY/pcOlX6TePaL7 OZzjJU2hxfoCo07Mf7Gq0HKyArVsU2dn+P3a5gFHtvlACODHUDPG3tLrz25G1kVU9CHX +CTRpVPlYsTxdF3H21wVoT1acllbFlzfV04DrgTe69c9NoMCumi1cYbVEfERtILtDnsq yjTg==
X-Gm-Message-State: AOAM533F6ub7jY18/DctmvaJoAuycsmQBDNtcqGHrWt6reh01Mtylq8B z9DJZwfv0aLmBzES86cImn/89ikfF2QsVi/9iwLSsg==
X-Google-Smtp-Source: ABdhPJxEVdqajX1kgA68pKEWpW5v/FbZVSm63qMxZgG5B/um6mzFxWCZoCVABDyrEPO9kgzCGuYnWLMtpfeXUC6NfVo=
X-Received: by 2002:a05:6402:1115:: with SMTP id u21mr11692017edv.383.1617891688143; Thu, 08 Apr 2021 07:21:28 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Tom Herbert <>
Date: Thu, 8 Apr 2021 07:21:16 -0700
Message-ID: <>
To: Fernando Gont <>
Cc: "Rob Wilton (rwilton)" <>, Gorry Fairhurst <>, IPv6 Operations <>, "" <>, "" <>, "" <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [Tsv-art] [v6ops] [Last-Call] Tsvart last call review of draft-ietf-v6ops-ipv6-ehs-packet-drops-05
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Review Team <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 08 Apr 2021 14:21:35 -0000

On Wed, Apr 7, 2021 at 10:16 PM Fernando Gont <> wrote:
> Hi, Tom,
> On 8/4/21 00:51, Tom Herbert wrote:
> > Fernando,
> >
> > I will also point that the data of RFC7872 is not consistent with
> > header length being the top reason for drops. If I'm reading the data
> > correctly, the HBH options are drop at about 3-4 time that rate that
> > Destination options in that analysis. Since there both the same size
> > (8 bytes), it seems that the majotiy of HBH options are being dropped
> > because they are hop-by-hop options, not because the header chain is
> > too long. This makes sense, because of the original requirement that
> > all intermediate nodes must process hop-by-hop options, and we know
> > many vendors didn't implement then. That requirement was relaxed in
> > RFC8200, and so we'd expect drop rates to drop as nodes move to
> > ignoring HBH options instead of blindly dropping them.
> Again: this document is not trying to explain the numbers in RFC7872.
> PLease do read the abstract and the disclaimer, because you keep trying
> to have this document do something that it's not meant to do.

>From the draft:  "The Hop-by-Hop Options header has been particularly
challenging since in most circumstances, the corresponding packet is
punted to the control plane for processing.  As a result, operators
usually drop  IPv6 packets containing this extension header."

"usually" implies that most routers are dropping IPv6 packets with
Hop-by-Hop Options. However, no evidence for that is offered and in
fact the best data available, RFC7872,  shows the drop rate is less
than 50% six years ago well before the mitigation in RFC8200. IMO,
this wording is potentially a mischaracterization and an exaggeration
of the problem.

> You should also note that the possible impact on devices is dependent on
> the EH chain length. However, the decision to drop packets need not be
> based on the EH length -- among other reasons, because such information
> might not be readily available.
> Folks running a network can't be bothered digging into how many bytes of
> EHs each device they use can handle, and then be expected to figure out
> if there'ś any way to let only packets of shorter EH-chain lengths
> through. There are other problems to tackle day-to-day -- and this one
> is not even a problem: If I have no practical requirement to support
> them, and on the other hand there'ś risk in supporting them, I don't
> need to explain what my decision will be. You'll have a hard time
> explaining your manager or CEO why your network was brought down for
> supporting something you didn't need to support ("didn't need" == "the
> folk that pays the bill didn't ask for or care about it")..

Sure, tell me, as a host stack developer, what at reasonable minimum
length is for an IP header chain and I'll fix the packets I'm sending
so that the operators don't need to be bothered with this.


> Thanks,
> --
> Fernando Gont
> e-mail:
> PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1