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

神明達哉 <> Thu, 23 March 2017 17:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CC18312995F for <>; Thu, 23 Mar 2017 10:20:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.401
X-Spam-Status: No, score=-2.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.197, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 zV-j8lPC7MZM for <>; Thu, 23 Mar 2017 10:20:18 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 40A8B129970 for <>; Thu, 23 Mar 2017 10:20:18 -0700 (PDT)
Received: by with SMTP id p22so46453689qka.3 for <>; Thu, 23 Mar 2017 10:20:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-transfer-encoding; bh=H/L/+xJNj18ShnK7w8u+JvFDXNFthH/lubS/5tJ3z0Y=; b=F7CXUxEC2Prbnz9A+RoSQ5dMAe9duCAZNIZ24zr+P6ruDtA0cIgray+NHUM8RkOscU Bef4b8EdhA5vLeN/DnELfYhx+I/MM6mhJvHqLf4DU4f93vAET6QBy8wKoikSrgb2RpOT itbd4GLpS9E4dGnHkGtHIHAL9o9oz2g87LLUCmnak+6NUqoQxpOuZ2DX9ozCjOZTzJzO clznYm+in44LDqxo3vk5xsbD9Xn1HPa8A3QVu21jSeMotCOn1n8sqSq6oUcjzftp9Ph8 yKhnGfh6QYjmuZ4RlbQrgAYUA3SuMAeRNITHCWRi5PECBNXnL22f5U2Wl2rWtR6eMPHt 5XRA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc:content-transfer-encoding; bh=H/L/+xJNj18ShnK7w8u+JvFDXNFthH/lubS/5tJ3z0Y=; b=smoeKqtNrtS31+kNzgsmL9sjaVCE32ltVz2lkMidVOxaiaWJnqe+eJetSWweZT/21+ RLlBFpTFBPvu26xHBzWO9AoS5nvda+B3IFTQX6+BnO+TcjYCfia8AGkfVs6szdGcDMbY GXx5agGZsn1NR51jaDFaCMcb8ST+80GUBVLJ06MWg05woOJV4qtBKvcMOS8Q+60Ey99B MJhFB4B29Ts3mGuHOyG5fTHunBHnbEHoUUemyPna+fhl3vkYrPc15pTKlgnSDjEzdnKa gLgDhH0MfWxKGCTVF6xDK7Y9dkR55B88aDCksm8vE7mPt3eQ0k216ZsC01v8OPRSbZDX tcig==
X-Gm-Message-State: AFeK/H1dOa8zjU9eSmlB2lHlv0+PaIL+5Ja6i0L/KMUTphbA+vvpii3YYIKhTI8R4g0doBy6oMZN7ztrFioYNg==
X-Received: by with SMTP id j131mr3009663qka.19.1490289617157; Thu, 23 Mar 2017 10:20:17 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Thu, 23 Mar 2017 10:20:16 -0700 (PDT)
In-Reply-To: <>
References: <>
From: 神明達哉 <>
Date: Thu, 23 Mar 2017 10:20:16 -0700
X-Google-Sender-Auth: 1lsABSu54axv0Lf9onXjsJaRp4s
Message-ID: <>
Subject: Re: Feedback on the use of Hop-by-Hop options extension header (draft-francois-dots-ipv6-signal-option-01)
To: Jérôme François <>
Cc: IPv6 List <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 23 Mar 2017 17:20:21 -0000

On Wed, Feb 8, 2017 at 1:17 AM, Jérôme François <> wrote

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

I've just (quickly) read the 01 version.  Regarding the header
insertion, I think the conclusion has now been made in the context of
rfc2460bis, but that aside, it was not really clear to me from the
draft text that it intends to allow an intermediate node (= DOTS
opportunistic-capable router?) to insert a new Hop-by-hop option.  If
you're going to avoid insertion as a result of the decision on
rfc2460bis, that will be moot anyway.  But if you plan to keep it
(possibly as post-rfc2460bis fodder), I think the draft text should be
much clearer on the intent.

Some other comments:

- I suspect this use of Hop-by-hop options header could be considered
  a layer violation; my general understanding is that HbH options are
  intended to be used at around layer 3, but the proposed use seems to
  belong to a much higher layer.  I'm not a layer-boundary-police
  officer, so I personally wouldn't be opposed to the idea just
  because of that, but I can easily imagine some of those officers
  will complain about it.

- (a minor point) in section 1.2 the draft states:

   an application layer (DNS) attack [rootops-ddos]. Each one of the 13
   root server letters (A--M) was hit by attacks peaking at 5 million
   queries per second.

  This could be misleading.  Root DNS servers are highly distributed
  using anycast today, and there are actual several hundreds server
  instances.  And in that sense "each one of the 13 letters" is
  ambiguous: whether it's each *one set of servers* of each of the 13
  letters, or it's each instance of hundreds of actual servers.
  Actually the referenced document ([rootops-ddos]) is also ambiguous,
  so it's not really a fault of this draft, but it's still better to
  be clarified or to find another clearer example.

- Section 5:

   [...] At DOTS capable
   nodes (client, gateway and server), it requires a service interface
   used by upper-layer protocols and application programs to ask the IP
   layer to insert and listen to the Hop-by-Hop header option in IPv6
   packets with the content and strategies described in Section 3. A
   DOTS client invokes the service interface to insert the option, A
   DOTS gateway invokes the service interface for listening and
   inserting the option, and finally a DOTS server only invokes the
   service interface to listen to the DOTS signalling option.

  At least for the actual source and destination nodes of the packets,
  I believe the advanced socket API (RFC3542) could be used for this
  purpose (unfortunately, though, it's not as widely implemented as
  the basic API).  You may want to refer to RFC3542 here.

JINMEI, Tatuya