Re: Network Tokens and HBH option

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

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

Tom

>
>
> On Sat, Jul 11, 2020 at 12:54 AM Tom Herbert <tom@herbertland.com> 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.
>>
>> https://tools.ietf.org/html/draft-yiakoumis-network-tokens-01
>>
>> There is also a mailing list in
>> https://www.ietf.org/mailman/listinfo/network-tokens
>>
>> 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
>> ipv6@ietf.org
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------