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

Nick Hilliard <> Wed, 29 July 2020 20:46 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 253E03A0EF2; Wed, 29 Jul 2020 13:46:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id k_8GXoT3yR-w; Wed, 29 Jul 2020 13:46:37 -0700 (PDT)
Received: from ( [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6DDEA3A0EF4; Wed, 29 Jul 2020 13:46:37 -0700 (PDT)
Received: from crumpet.local ( []) (authenticated bits=0) by (8.15.2/8.15.2) with ESMTPSA id 06TKkXBq094749 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Jul 2020 21:46:34 +0100 (IST) (envelope-from
X-Authentication-Warning: Host [] claimed to be crumpet.local
To: Tom Herbert <>
Cc: IPv6 Operations <>, "" <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <>
From: Nick Hilliard <>
Message-ID: <>
Date: Wed, 29 Jul 2020 21:46:32 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:52.0) Gecko/20100101 PostboxApp/7.0.24
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 7bit
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 20:46:40 -0000

Tom Herbert wrote on 29/07/2020 17:37:
> 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).

there are often no mitigations as limits are often related to hardware.

> 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).

First, only SRv6 proposes to add EHs and I think we're all familiar with 
the difficulties that were outlined in that discussion.

So in the general case, it's up to the host to decide how many EHs to 
attach to a packet.  Obviously as there's no EH negotiation mechanism, 
there's no way for a host to know what will work and what won't, and 
even if there were, intermediate paths change so what might work on 
setup might not work later on.  We have the same problem with MTUs.

There are some limits already defined in IETF standards track documents 
(e.g. that you can have no more than a single packet with EHs attached), 
but real life limits are much lower.

It may be useful for a future document to quantify the problem.  This 
aim of this document is to state that there's a problem.