Re: [Network-tokens] Network Tokens and HBH option

Tom Herbert <> Mon, 13 July 2020 15:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0F3B13A13B3 for <>; Mon, 13 Jul 2020 08:41:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] 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 yU11w60yxZGA for <>; Mon, 13 Jul 2020 08:41:50 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::542]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 579133A14D5 for <>; Mon, 13 Jul 2020 08:41:36 -0700 (PDT)
Received: by with SMTP id a1so8619469edt.10 for <>; Mon, 13 Jul 2020 08:41:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=d7/2CtClQzmju+sE35F0A2H1N12v1TIR4CsVVBnjlR0=; b=0tX0eKi3aBIaDA85Dm2/ZvoF2hbULV8IH1zkPXkp5pxODOsWARTHgtah2r0GFNdRZn qo1zl5WOu5Fr/DiUy57f5MhwyXIRllB7gMm6lMZZi1r83oFb4S2C195J/QyGtr/XDU59 wQb4EAQnuAZ9TYFQLjJLhMEYT1Dc3BhX8unO4P6y/xAmb3X5h+HiqylrvD3UdCpC7GIp lQuEb++zcxiczFOL9gEUwga88JJttu6f8274XSPqr1yCS+rxdr3T/z2hBQPsGRhjySCL JyHpuRHCVZnUEaQ0Zqi06Ih9o4d8XNEqh2/nU7i8BNZ0q6W67ZhJzdMF+EwI1w31JoCr SRaQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=d7/2CtClQzmju+sE35F0A2H1N12v1TIR4CsVVBnjlR0=; b=n1EpbXPxOyTTJg7yxa8oHbwMZz42YnUyaYthn7tbSqKrsl1tkNHjMWjAlZglPSXoCG xUr1kNBsGU7Udh2EwsHdRb+BB5I1v1SYAURhO9/8RO5JbsnbJx0kVWAGA7ejVB2eMYhG UDHPuq4w/yO1p5SLiLb8xSqjPu6U3r3rvNxMjAudjktIoRMamOYwpNa+ETWqP/wMEh71 XEwisrG5P6Ee0YTKrTHxkvVizGLVrSMcxpmv9FqrsOYiDaPJotXnS9zmfnVBQtyjEswX 5nQL9yx1L5Gr/OtTr5lqyZ3TTvfOCQBxpfeg8nodjmEAem2GvHJa7Hy2f8tMvFf2BeKs Vh5g==
X-Gm-Message-State: AOAM532cw59LFWQIOeWHWuVyc7zc8C5yIu0mHVXYw+EZLlO9bQrruQQ7 +nk+xr29Xc9YSwwMBOPd7zFsqlQ6yZykcS9kqe1rOA==
X-Google-Smtp-Source: ABdhPJwYtfagm3xXw/6TK+EO3xYV3lydvWQv+3brlAPfT6aWl8l4fI6WpRK4/zRxVgvOmXl39y2YmCMEC1PwVrCwIsQ=
X-Received: by 2002:aa7:d5cd:: with SMTP id d13mr14988eds.370.1594654894708; Mon, 13 Jul 2020 08:41:34 -0700 (PDT)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Tom Herbert <>
Date: Mon, 13 Jul 2020 08:41:23 -0700
Message-ID: <>
To: Lorenzo Colitti <>
Cc: 6MAN <>, Yiannis Yiakoumis <>,
Content-Type: text/plain; charset="UTF-8"
Archived-At: <>
Subject: Re: [Network-tokens] Network Tokens and HBH option
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussion list for network tokens <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 13 Jul 2020 15:41:52 -0000

On Mon, Jul 13, 2020 at 1:14 AM Lorenzo Colitti <> wrote:
> Is a hop-by-hop option the right tool here? They have several disadvantages:

>From a protocol perspective, Hop-by-Hop options are not only the right
tool, but they are the only correct method to perform host to network
signaling robustly beyond whatever information is in the IP header.
The alternatives like DPI in transport headers payload (see SPUD for
instance) aren't robust in the end and inevitably lead to more
protocol ossification and limits to how we use protocol.

> The presence of IPv6 extension headers often causes packets to be dropped, so anything that relies on them is impossible to deploy reliably on the Internet.

This is the typical RFC7872 argument. Network tokens can be scoped to
local domains that support them. It's the network that provides tokens
to applications, so the network should be able to know if the tokens
are usable to the requested destination.

> They don't work with forwarded traffic (e.g., a mobile hotspot) because routers aren't really permitted to add extension headers.

The primary use case is UE to first hop in the network. It's possible
that the network can remove the options at the point if they are not
needed beyond the first hop. Likewise the options can be removed at an
egress router before sending into the Internet. or at the egress
router in a limited domain. draft-herbert-6man-eh-attrib-01 defines a
mechanism to safely remove options.

> They are expensive because IIRC for a long time the standards said that all intermediate nodes on the path must process them. Many router implementations do not do this, but probably some do.

As I said, we can restrict use to limited domains as necessary where
the nodes properly support hop-by-hop options.


> On Sat, Jul 11, 2020 at 12:54 AM Tom Herbert <> wrote:
>> Hello,
>> This is a draft on "Network Tokens" which is a form of host-to-network
>> signaling for the purposes of providing a highly granular network
>> services and QoS to applications. A primary mechanism to carry the
>> signaling is expected to be a Hop-by-Hop option.
>> There is also a mailing list in
>> We are planning to present in tsvwg and app aware networking and
>> possibly have a side meeting on this topic in IETF108.
>> Thanks,
>> Tom
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> Administrative Requests:
>> --------------------------------------------------------------------