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

Tom Herbert <> Wed, 29 July 2020 16:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B656B3A0C77 for <>; Wed, 29 Jul 2020 09:37:56 -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 ugHqIsjX6RZs for <>; Wed, 29 Jul 2020 09:37:55 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::534]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2DAA53A0C70 for <>; Wed, 29 Jul 2020 09:37:55 -0700 (PDT)
Received: by with SMTP id a14so912822edx.7 for <>; Wed, 29 Jul 2020 09:37:55 -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; bh=LeNuW5i6UUE8+F2OrlGZGXri2WjFejoPetzMRME7NOM=; b=Ruz/7OmkSMXpzjtxMqaDuem8Kom9y41dvlMnXdemnUHQXBUDHp8ljCDrNvozSkUOsP ifmGpHEimk39dWQFbj4ijID0IqyrkLBPt/Bik0Uk+tZgDMxmtxUveX8Thi1B7Zu34OfD nxp8ZGwhiRnUF3IKjtFMB4Jsn7KXyYYO8NOc2t2QkB/qGC5+hmVuZRXG5585Cz/q5k28 Mwdzygx0L2I55IGtpvJzPs/NPxsPbBP9FKODFYWKfnR2grPpVLU7A86fTvhwCY0+YJWX BQmwAzjdgy+9gDC4JCoeRfjmSky0AQ5aL1Nh1PFMR+LMaCjdSlWSWTah8G05AowYlwML 5NgQ==
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=LeNuW5i6UUE8+F2OrlGZGXri2WjFejoPetzMRME7NOM=; b=SiDmCM/wjzt+l7hKGM91/vlfhAX2BM1m9kI7f6+kOH94A+StXGKy0yY9DGIWOWkFmz PZ+ScAk0h09lsUUiIp1GoMumYjqL3698lyNTjNvkhmK6d4tPwINMBJXZE7jVVRxh4pm8 o78jSYUNfE6yZe6WEJ/HzYs3eIvgZRhB3TTMn+C4WDDN64Fx6urM6O7IU5kfpFzdFyQJ NjUJ5rBclH0yqfzmYoCjmuPoGLMzFm3+oypQLtJd05I7QrsnbYHSPZksAho0ofjhnK6d Qi5L2nSNrtS18fJv+KMX+WufEtu4w+yLWgP1zbhIXo6UV6Btdys3wAoHJ+TXJZdvc5qY JVHQ==
X-Gm-Message-State: AOAM531VRj26utG2N59jSHyRmxjKNFg+UgTVS3SvibRwWl+GeerRMB5I 2EbfPLU8cFk4TEji32rySw1AxsFU1c+cAh7v6X9Log==
X-Google-Smtp-Source: ABdhPJw+sc1ndxGvn0iroeF9uBJIuoZmobc6SXVgWQDnQSQp6CA8+s4EKeckdomNfwXaxnwFbbQYeVPYmEyo8rI+SZ8=
X-Received: by 2002:aa7:d5d0:: with SMTP id d16mr1664765eds.212.1596040673474; Wed, 29 Jul 2020 09:37:53 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Tom Herbert <>
Date: Wed, 29 Jul 2020 09:37:42 -0700
Message-ID: <>
To: Fernando Gont <>
Cc: Brian E Carpenter <>, Geoff Huston <>, IPv6 Operations <>, "" <>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <>
Subject: Re: [v6ops] Operational Implications of IPv6 Packets with Extension Headers - Load Balancer
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: v6ops discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 29 Jul 2020 16:37:57 -0000

On Tue, Jul 28, 2020 at 11:14 PM Fernando Gont <> wrote:
> Hi, Brian,
> On 29/7/20 01:03, Brian E Carpenter wrote:
> [....]
> >> It seems evident that the IPv6 packet structure makes a cost-effective
> >> implementation rather difficult. Since engineering does not only have to
> >> do with science, but also with economics, it follows that:
> >>
> >> * Folks (group #1) will not be willing to pay for features that their
> >> clients do not explicitly require.
> >>
> >> * Vendors (group #2) will not spend cycles on something which will not
> >> get them money in return.
> >>
> >> * Other set of folks (group #3) will not actively try to leverage
> >> features with a high failure rate, since they would also need to
> >> implement workarounds -- and if the workarounds already solve the
> >> problem, with a much higher success rate, there's not much of a point in
> >> spending time (and ultimately $$) in the feature that usually fails.
> >>
> >> * Users (group #4) use whatever solves their problem.
> >>
> >>
> >> We may be unhappy with the above fact. But unless we're willing to pay
> >> the bill :-), I'm not sure to what extent embarking into a Crusade would
> >> solve the "problem".
> >
> > Not what I meant, really.
> FWIW, I do agree with you. My comment was a response to Tom where he was
> objecting to folks that, for one reason or another, happen to drop
> packets. (in this particular case the advice given by JOel in his
> presentation)
> And what I meant is that rather that being mad about them, one should
> try to find the reasons for which they are resorting to that (which is
> what this document is meant to), and then figure out and do what we can
> from a protocol engineering perspective.

I agree with that and I do appreciate that section 3 of the draft
describes several of the mitigations to make EH processing more
palatable like the provision of RFC8200 that allows nodes to ignore
HBH and the limits in RFC8504. It might be helpful in the draft to
mention the relevant mitigations when discussing specific reasons for
drops. For instance, if DOS is being discussed then RFC8504 should be
mentioned in reference since the one purpose of limits on number of
options is to mitigate DOS attacks (i.e. without limits an attacker
could fill an MTU with 100s of unknown HBH options that an
implementation, SW or HW, will choke on it).

Another area that should be elaborated here, or maybe necessitates a
separate document, is the parsing buffer problem described in section
5.1.1 by "If an IPv6 header chain is sufficiently long that its header
exceeds the packet look-up capacity of the router, then it may be
dropped due to hardware inability to determine how it should be
handled.". I believe this is a real problem, but it's never been
quantified. For instance, when a host creates a packet how can it
possibly guess than some router in the path will drop the packet
because the header chain is too long (not just IPv6 header chain by
the way, but really all headers a node needs to process which can
include transport or even transport payload). The draft for sending
ICMP errors when packets are dropped is in the RFC editor queue, but I
believe we can provide some sort of guidance that intermediate nodes
are expected to be able to process at least X bytes of headers. This
probably needs to broken down by what headers nodes process: a
forwarding node might just look at IPv6 header and HBH options, an
intermediate destination needs to look at routing header, a stateful
firewall needs to get transport header, and application layer firewall
needs to go even farther, etc.


> > 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.
> That's in part correct. However, for cases where standards track
> documents implementation become unfeasible or cost-ineffective, one may
> need to consider being more flexible and reconsider the spec.
> A good example was the IPsec requirement in an early revision of Node
> Reqs: it was words on paper that would never be complied with - so the
> spec was changed to reflect that.
> I'm not necessarily saying that this is the case here, but rather that
> that's an option that should be on the table.
> > 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.
> I retrospective, if it cannot depend on the FL (which I agree), is there
> much of a point in using it?
> Thanks,
> --
> Fernando Gont
> SI6 Networks
> e-mail:
> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492