Re: Feedback on the use of Hop-by-Hop options extension header (draft-francois-dots-ipv6-signal-option-01)

Brian E Carpenter <> Fri, 10 February 2017 20:26 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3A540129BA7 for <>; Fri, 10 Feb 2017 12:26:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 Ph4Uo3divuQ4 for <>; Fri, 10 Feb 2017 12:26:04 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400e:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C9B89129587 for <>; Fri, 10 Feb 2017 12:26:04 -0800 (PST)
Received: by with SMTP id 14so13225992pgg.1 for <>; Fri, 10 Feb 2017 12:26:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=subject:to:references:from:organization:cc:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=TXDrqYnJXD+48HipX1qxjZzbUR7Ns+yANMPG9q/OJtY=; b=LwLQn0IKnxmamkD/MJyr5Q5T39el1G1QqtJN3PWlcGIxLMsqnC2izqOX2AOeSfkwWz qTxa2fqVycxdHckQ8SkjShAfM20nEtDFUBP78XlWNMa5Jjo+j2GJ55r5EugoCbMu1pEi xyL3EE6loDo5Omw5dShusclu7Draq5uezmRDJPEQGV//RWBVadRvBg3yT+qOMjN+mW1L +njnpTsXSL4PrCYK3FNbpxGd1H/StYb0L9PU7uQZr799GS64E3xWkBtRsnBpbk6xyftF b336o5ocEm6aDShk5mjnV7lXNVpZRRetM6kcYzDGCQm5qB55ErXt3ppK0IhLenQmarzc 97hg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:subject:to:references:from:organization:cc :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=TXDrqYnJXD+48HipX1qxjZzbUR7Ns+yANMPG9q/OJtY=; b=HCymbhLw0a++ZSodzcmF0qrWxnMMUiOuS6ak0b4d2YwBKG+hzB1sdFE1zv4h5lop/B JMnjAX6uE/8UPh56w/xEke8SHRW1IByDQvP5+YkBflOWW1RIuZQReS8k0RvSj81OGSzx l9yJ3LR4/a6rLrZyT7NvGuH9K2ZLFpBzcJTFq3lwAxJU9clGJHNLPm2OA2RCe3kvmEFu y2oPgJMvx1oIrpesQZ+M34lEJuN/meYsuSH6RvJtfo0aBQKa957ov3NinTlJ3hrJ/26T y2o+XGB7lcc2lwq96sJ7MW7+Jom3vYqva6Yy1PXy6AQAyoXkBIaASzapkSbi13FP7cIG pyqw==
X-Gm-Message-State: AMke39nkHLIcXFIYLN0CPT4UdS9Tn6bkcf1Zv3IgAMCzKenpYDLUsJWhc5IAY3mQ8qVJYw==
X-Received: by with SMTP id t184mr12918343pgd.129.1486758364176; Fri, 10 Feb 2017 12:26:04 -0800 (PST)
Received: from ?IPv6:2406:e007:769c:1:28cc:dc4c:9703:6781? ([2406:e007:769c:1:28cc:dc4c:9703:6781]) by with ESMTPSA id p14sm4143860pfl.75.2017. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 10 Feb 2017 12:26:03 -0800 (PST)
Subject: Re: Feedback on the use of Hop-by-Hop options extension header (draft-francois-dots-ipv6-signal-option-01)
To: =?UTF-8?B?SsOpcsO0bWUgRnJhbsOnb2lz?= <>
References: <>
From: Brian E Carpenter <>
Organization: University of Auckland
Message-ID: <>
Date: Sat, 11 Feb 2017 09:26:10 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
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: Fri, 10 Feb 2017 20:26:06 -0000


I can't do better than what we wrote in RFC7045:

2.2.  Hop-by-Hop Options

   The IPv6 Hop-by-Hop Options header SHOULD be processed by
   intermediate forwarding nodes as described in [RFC2460].  However, it
   is to be expected that high-performance routers will either ignore it
   or assign packets containing it to a slow processing path.  Designers
   planning to use a hop-by-hop option need to be aware of this likely

   As a reminder, in RFC 2460, it is stated that the Hop-by-Hop Options
   header, if present, must be first.

If the HbH option type is 'may change en-route', you can rewrite its
contents, but you can't change its length. And as you have understood,
most people believe that RFC 2460 says you must not insert one.


On 08/02/2017 22:17, Jérôme François wrote:
> Dear all,
> We are working on a DOTS draft about using the Hop-by-Hop option header
> to encapsulated DDoS signaling  within network to enabel a kind of
> epidemic propagation
> (
> Some comments have been raised considering the real use of the
> Hop-by-Hop option. We would like to ask you your feedback about using it
> for very specific signaling among trusted parties. In particular, do you
> know any reference to a particular use of Hop-by-Hop in a real case.
> We have also followed the mailing list discussion about header insertion,
> which obviously concerns our approach since we are extracting and inserting
> some info in headers on the paths. Even if this is is limited to specific 
> routers in a single domain, we understand that it can create problems and
> should maybe use packet encapsulation.
> Best regards,
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> Administrative Requests:
> --------------------------------------------------------------------
> .