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

Tom Herbert <> Sat, 20 February 2021 19:46 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 807733A0A25 for <>; Sat, 20 Feb 2021 11:46:27 -0800 (PST)
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=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id fxOzMPpLCoHi for <>; Sat, 20 Feb 2021 11:46:26 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::62b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 113CF3A0A02 for <>; Sat, 20 Feb 2021 11:46:25 -0800 (PST)
Received: by with SMTP id bl23so22323276ejb.5 for <>; Sat, 20 Feb 2021 11:46:25 -0800 (PST)
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; bh=orQMmssFBgeXTZKdVVe/L3nBQYOqF4fFKFghBxuxEmM=; b=dLU6ha2k7HowKpuKOBvfH8+orHys5lC+GJ53s48daQGHrZRNqVcL6fn05J5tJ6VoOA 31el9kyCkrUxt5yIX3a/NRR3h6xwNAb3Y7+NHn+JYDCHb4gIzmSsc6mhihvSj1W8M13R RJIa0A6bO7LIuu+nQR7Lro+p7csgYPSF5+PrSSAOrR7kvIfJZv1SX9pwHgJLeW5arNqs Y4D60xS5WTK/PCvT1pCyzxMnmN9ln0KUV/aYAbJ5uBo/JgZdj6ZB7nd4FkKVoCZ5yg0e Ab5riKimxDmtznpoRuUdq5Q1UiL49B/4ke00ztnBGsix5WKc5BMyT7j2vGUUIJzH/wBI eftA==
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; bh=orQMmssFBgeXTZKdVVe/L3nBQYOqF4fFKFghBxuxEmM=; b=HifgT44opybe0+10nhA3UtaTA+gzyvAKvv66+F1He7N80X41fEKbcluf2juSl8lZKD 4dIlv1dEO1UTx2HSHWWcyjQBhBG33AIkdnzTollZIesGImSAO3/CJhnJzxJGug/lDOXN Y4mEmHPww8PSukey73duTK7VeR5hOn3JG23xjXKmfEtNznzxRk2gxYpEVyg1RVUhxtkX OstxiyrIXrjA81FezJj5VGBmLQp7rt8HqEtuoUedQm8f97IgpEBeYxOmt2bjS5P/1wju M61/M+jJnq9Ze9rcGzZHiavOFmNNHlk5z62DwhhCy+1qlaL7oSBx2/g0IYnSpc5Mc+l0 ZYQw==
X-Gm-Message-State: AOAM533qi5KK/8j+loC5xzWy5C0zjAJFo9NeBHF9WgwLrg7dKpIz71U2 +kkcwdV+ZP0Dmt25KGLZCticHrUpX2y0dECL93oFuA==
X-Google-Smtp-Source: ABdhPJxgOIpwq1wWk+CdcLzQFKMbYkY9/wxDk1lOkNjrHvWezyCzrEs5S5Wb6vlPBcRPcAbI4kLC1/ELWKMTQ005Ysk=
X-Received: by 2002:a17:906:3915:: with SMTP id f21mr11558169eje.295.1613850384326; Sat, 20 Feb 2021 11:46:24 -0800 (PST)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Tom Herbert <>
Date: Sat, 20 Feb 2021 12:46:13 -0700
Message-ID: <>
To: Nick Hilliard <>
Cc: Fernando Gont <>, Gorry Fairhurst <>, IPv6 Operations <>,,,, Brian E Carpenter <>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <>
Subject: Re: [Tsv-art] [Last-Call] [v6ops] 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: Sat, 20 Feb 2021 19:46:28 -0000

On Sat, Feb 20, 2021 at 12:10 PM Nick Hilliard <> wrote:
> Hi Tom,
> Tom Herbert wrote on 20/02/2021 15:32:
> > This is reflected in the statement: "If an IPv6 header chain is
> > sufficiently long that it exceeds the packet look-up capacity of the
> > router, the router might be unable to determine how the packet should
> > be handled, and thus could resort to dropping the packet." It's not to
> > me clear what "sufficiently long" means;
> Is this just an issue of dialect?  The term "If an IPv6 header chain is
> sufficiently long that..." just means "If an IPv6 header chain is long
> enough that..."
> > in particular, such a
> > statement isn't helpful to the host stack developer trying to figure
> > out if the packets they're creating will be properly forwarded.
> That's something that should be addressed in a future ID.  Right now
> we're concentrating on documenting the problem.

Maybe so, but without further details I believe the way the problem is
being documented is ambiguous and unenlightening. Besides, there has
already been work in this area that really could be cited here. For
instance, in RFC8883 the different ICMP errors reflect several
different ways and provide a lot more detail as to why nodes might
drop packets because headers are "too long". That RFC lists the
priority of ICMP errors as:

 1.  Existing ICMP errors defined in [RFC4443].
 2.  "Unrecognized Next Header type encountered by intermediate node"
 3.  "Extension header too big"
 4.  "Option too big" for length or number of consecutive padding
options exceeding a limit.
 5.  "Option too big" for the length of an option exceeding a limit.
 6.  "Too many options in an extension header"
 7.  "Extension header chain too long" headers exceeding a limit.
 8.  "Too many extension headers"
 9.  "Headers too long"

Numbers 3-8 represent reasons why nodes might drop a packet with
extension headers. Number 9 encompasses those cases where a node
parses beyond the IPv6 headers chains (for instance a node that parses
into GRE encapsulation).

Give that these classes are documented, then the obvious question is
what are the common limits that should work. RFC8504 does this for
some of the limits that are more apropos to the host; hopefully, an
outcome of this draft will define some practical limits for routers
and set some expectations about what should work.


> Nick