Re: Hop-by-hop options [Re: Routing directorate review of draft-ietf-6man-rfc2460bis]

Tom Herbert <> Thu, 02 March 2017 21:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1EB0012967B for <>; Thu, 2 Mar 2017 13:36:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] 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 ibjoq3DhJg1U for <>; Thu, 2 Mar 2017 13:36:39 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400d:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1BBFC129674 for <>; Thu, 2 Mar 2017 13:36:38 -0800 (PST)
Received: by with SMTP id m67so31369544qkf.2 for <>; Thu, 02 Mar 2017 13:36:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=wbj4+3nQZOlUvjlj9E1rdHY/CoHAepBEQGTnaZyBhXI=; b=PFGzsTmPuDnHhCD1sYdFZpVUz8nCdJGSQIKJKKN/KTMZB9fLRIiBVlO+ytGGaByWHR D6a7dft+h4gjI4wXYLRbgQNw/3mIAz7bixfbscEsCzpDteRAJPpQmt09kDY9qFRzjBUp VpWyUTlGfAlMwPLH0D/zac2HlyWl/W/EHWbtP3YQJnOFer5eqJ01ZSR8U5S0THBEa6Xt RLPIH4wSSxZr9Imw773tkD8zlr+QhF2fKAYXXil13icq7JrpbUV4x649PmTHPyDm18Yp YvTwSPaQsp92fBVFHitobFvtR8Ajam1gZeB8ZJ0uKqfXoD/j2NZtOZF5G3L1+e2SEuuW YCsA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=wbj4+3nQZOlUvjlj9E1rdHY/CoHAepBEQGTnaZyBhXI=; b=m1ZCv3CHHcvGKePKlZvzJqSWlocVZmW+eUU7jAm4VB0JFQy5AOS4H9RiENuQNdks+K teqKS5mRmhFdwUFIdMxN1N6C1D5c/OXHpeaU4F8sgxvp6sUM3RfhLt2StBrm7k6P89lU DoQDmIZ71V0oX97z43Gw5hxELr106B+ThHxYxcLQR2yc+nRypk8uHNeuFe3aeJ5PVIXw N8JB5YTpbTsp0YBd8NUDcSx7jhdpsh+GVRL4F0XkiMPkChw7nJxXXwmPsT8KoJtd/SM0 OjwhxuXHjRPyOMTepoeo3wukv75QIuTqblmn3bA20+5pkLqzu+PjBS4kshouusv1ILDI FG9A==
X-Gm-Message-State: AMke39nylHk0sSlKTUTuR3EBBvgA/L5q6Rdq8qwqGWlRCCT30BEPRLy7/V6LIIWnPb6Zfl+F+pt3Zf0S6MGGXQ==
X-Received: by with SMTP id 7mr17744274qkh.228.1488490597056; Thu, 02 Mar 2017 13:36:37 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Thu, 2 Mar 2017 13:36:36 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <>
From: Tom Herbert <>
Date: Thu, 2 Mar 2017 13:36:36 -0800
Message-ID: <>
Subject: Re: Hop-by-hop options [Re: Routing directorate review of draft-ietf-6man-rfc2460bis]
To: Brian E Carpenter <>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Cc: "" <>, "" <>, "Papadimitriou, Dimitri \(Nokia - BE\)" <>, "" <>, "" <>
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 02 Mar 2017 21:36:40 -0000

On Thu, Mar 2, 2017 at 1:25 PM, Brian E Carpenter
<> wrote:
> On 03/03/2017 10:02, Papadimitriou, Dimitri (Nokia - BE) wrote:
> ...
>> Section 4.8: states "New hop-by-hop options are not recommended because nodes may be configured to ignore the Hop-by-Hop Option header, drop packets containing a hop-by-hop header" does this configuration change because options are new or old ? there seems to be confusion here between "new vs. existing" options and "intermediate nodes MAY be configured to ignore/drop packets with these options included".
> Middleboxes *might* be configured to do something sensible with existing HbH options (such as ignoring them) and something annoying with unknown new ones (such as kicking them to the slow path or dropping the packet). So yes, the situation is worse for new options than for ones that have been defined years ago. But they are both risky.
Right, but in the current state of things any EH has proven hard to
successfully deploy in practice. IMO it's more of an implementation
problem that needs to be addressed rather than a protocol
specification problem. If the recommendation is to not create new HBH
options because of this it seems like this affirms protocol
ossification and maybe we've lost the battle!