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

Mark Smith <> Wed, 08 February 2017 13:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5542B12949D for <>; Wed, 8 Feb 2017 05:29:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.499
X-Spam-Status: No, score=-0.499 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, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id nEIlQwKTDk8E for <>; Wed, 8 Feb 2017 05:29:43 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400c:c08::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4641A129A2D for <>; Wed, 8 Feb 2017 05:29:42 -0800 (PST)
Received: by with SMTP id 96so109068527uaq.3 for <>; Wed, 08 Feb 2017 05:29:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=nvhlRCD0OkYPoeCS34Ft06LyGH0YLwX3lqVg+FJ2dMo=; b=efaO1jX61scNW2W8tPIu0IWgTNfcqirHqxSbRlUcXK6zfjX26lpse3zXVu84EjJZgz g4QDYCVmqz0idazR+7GW25gQtcOKQqDljBZ1Ga3Nwd1vcqFwigGHF7zkyAWxDOGXc/8C jyxEZyu/MQTZCmy4iX5VrKzfkbaZ1F7meb2MObbuHDuacql00r5iGtAKCcWoJO9OryCJ xIly9yM49rd1BiIVjFYPb7kWXvoPHBv3d1TmbCjVeiJnQw+E9CNqsXgSdRrzwRUwKQjC yHV4hBbTilCrjQTIX2sScy8W/tJq5Y9Nb22bfyTv1zzQuuJIXQLbav1JGt9FcHEmM+yO rTMg==
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; bh=nvhlRCD0OkYPoeCS34Ft06LyGH0YLwX3lqVg+FJ2dMo=; b=jZR9Gwi/x/D8rvtsC/yM7xd5BK1zRW7MZV8QizVSDY6XW67oemTZwn5yIhwUCrbPN3 w+bwFce7vPZdGYjU0Tn3ueEiCN41po6ldpyajX/QbSxIo0mfFT03jfUExztKa0ggyz1D 997yCXrsGx7Rz+qNfhcD8eOe6cfGCPr9Pz1dEA1A4an2B138remwAta/1pD0L6OBkg23 40D3b9yotz3rLStBNTViZAWYNcX8HB/qk/J7sFeOKnlRIwb3oBq6HfEnbbyRewxkUpks G5PtW7aI/zn5xoLtjLr3VHbIUm2UTWQkvtaApJXD0dSalGradOZd79hfqEfJZPq5EYSt L7wA==
X-Gm-Message-State: AIkVDXIz+u5GDS4mnDS1eLWZauI00ATLWUCcyJRPs49U3YqVho6t+ZkSEcdXsWAuiY4QCfKxACgsxkEKVmCgYQ==
X-Received: by with SMTP id f57mr8887038uaa.18.1486560581363; Wed, 08 Feb 2017 05:29:41 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Wed, 8 Feb 2017 05:29:40 -0800 (PST)
Received: by with HTTP; Wed, 8 Feb 2017 05:29:40 -0800 (PST)
In-Reply-To: <>
References: <>
From: Mark Smith <>
Date: Thu, 09 Feb 2017 00:29:40 +1100
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 <>
Content-Type: multipart/alternative; boundary="94eb2c1917ce63ac8d054804db35"
Archived-At: <>
Cc: 6man WG <>
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: Wed, 08 Feb 2017 13:29:44 -0000

On 8 Feb. 2017 20:18, "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,

The only place it will be guaranteed to be limited to a single domain is
the specification. It is not possible to make and rely on that guarantee in
implementations, as implementations can be imperfect.

If the packet leaks out of the insertion domain, the inserter won't know
it, because they'll suffer no, no obvious and/or no immediate consequences,
and the receiver who does suffer consequences with have no ability to
easily identify who inserted the EH or even if one was added by an
intermediary while the packet was in flight.

we understand that it can create problems and
should maybe use packet encapsulation.

That would be best. It clearly delineates between what was the original
packet and what was added, and adds another set of source and destination
addresses that identify what domain/device added the information, and what
destination device within that domain that  the added information was
intended for.

Encapsulation has a higher per-packet overhead, however it provides
attribution of the addition and prevents misinterpretation of the
additional information if it gets sent somewhere it shouldn't (an
encapsulated packet leaking out of an encapsulation domain should be sent
back towards it because of the encapsulation destination address, or will
be dropped because the encapsulation destination address is unreachable
outside the domain.)


Best regards,

IETF IPv6 working group mailing list
Administrative Requests: