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

Brian E Carpenter <brian.e.carpenter@gmail.com> Fri, 10 February 2017 20:26 UTC

Return-Path: <brian.e.carpenter@gmail.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A540129BA7 for <ipv6@ietfa.amsl.com>; Fri, 10 Feb 2017 12:26:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ph4Uo3divuQ4 for <ipv6@ietfa.amsl.com>; Fri, 10 Feb 2017 12:26:04 -0800 (PST)
Received: from mail-pg0-x233.google.com (mail-pg0-x233.google.com [IPv6:2607:f8b0:400e:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9B89129587 for <ipv6@ietf.org>; Fri, 10 Feb 2017 12:26:04 -0800 (PST)
Received: by mail-pg0-x233.google.com with SMTP id 14so13225992pgg.1 for <ipv6@ietf.org>; Fri, 10 Feb 2017 12:26:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; 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; d=1e100.net; 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 10.99.129.193 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 smtp.gmail.com with ESMTPSA id p14sm4143860pfl.75.2017.02.10.12.26.02 (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?= <jerome.francois@inria.fr>
References: <589AE235.6080808@inria.fr>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
Message-ID: <0b26fa99-2217-c139-e226-3568581173a5@gmail.com>
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: <589AE235.6080808@inria.fr>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/ohzpbzLbpNd5cMaNKjzKCUyjKlE>
Cc: ipv6@ietf.org
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 10 Feb 2017 20:26:06 -0000

Jérôme,

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

   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.

Regards
   Brian

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
> (https://tools.ietf.org/html/draft-francois-dots-ipv6-signal-option-01)
> 
> 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
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
> .
>