Subject: Future of hop-by-hop options ? (was: DISCUSS on draft-ietf-6man-ipv6-alt-mark-08)

From: Toerless Eckert <[email-masked]>
Date: Thu, 12 Aug 2021 17:17:50 +0200

There was a good discussion during todays IESG telecall about hop-by-hop
option behavior in the context of draft-ietf-6man-ipv6-alt-mark draft,
 but IMHO going into more general questions. So i wanted to comment only on those
longer term issues, but not about this draft.

I was wondering if/what we had anything written up already yet to document
the architectural challenges of the IPv6 hop-by-hop behavior and
expectations. If not, we should.

Warren made the main point that the core problem is that hop-by-hop options
will be filtered at domain edges if they are undesired in the network and
would otherwise burn router resources undesirable.

I mentioned at IETF111/6man what i think is the core requirement to overcome
this challenge, which is to have a hop-by-hop mechanism where we can reasonably
expect that all hardware can ignore it at line-rate (same performance as if
the option was not present). UNLESS the operator wants to explicitly support
the option.

IMHO, we can not rasonably expect this as a retrofit requirement for
the existing ip6 hop-by-hop option architecture, but in the first place
it would be good to have documentation outlining these type of fundamental
challenges, and possible solution direction (e.g.: such as what i proposed
or anything else).

Not creating work for routers was just one point. Filtering/authentication
on domain edges was also mentioned as core issues.

The main thing that had me worried about the discussion where comments made about the utility
of hop-by-hop options to be required to have enough utility to be enabled everywhere.

I think that is a non-useful bar, because i would see the mayority of hop-by-hop
processing to be only happening a e.g. the access-network SP domain, but
not necessarily on transit domains - and still have a lot of value. This
would imply the need to be able for an ISP to appropriately allow and
process hop-by-hop functions for traffic from/to its own subscribers (whee
offering processing of hop-by-hop options could be seen as even a monetizeable
value add), but ignore it in transit traffic going through the same domain.

At least, this would be another example of scenarios and requirements:
how to process some packets with an option and ignore the same option
in other packets... 

If we would document and agree on these type of scenarios as a
type of problem statement, we would be one step closer to even be able
to vet whether we could come up with good long-term solution proposal
against these requirements/scenarios.

Cheers
    Toerless

---

From: Nick Hilliard <[email-masked]>
Date: Thu, 12 Aug 2021 16:42:04 +0100

> expectations. If not, we should.

at a more general level, rfc7872 and 
draft-ietf-v6ops-ipv6-ehs-packet-drops describe issues with EHs.

Nick

---

From: Bob Hinden <[email-masked]>
Date: Thu, 12 Aug 2021 08:48:23 -0700

> On Aug 12, 2021, at 8:42 AM, Nick Hilliard <[email-masked]> wrote:
> 
> at a more general level, rfc7872 and draft-ietf-v6ops-ipv6-ehs-packet-drops describe issues with EHs.

As well as:

https://datatracker.ietf.org/doc/draft-hinden-6man-hbh-processing/
https://datatracker.ietf.org/doc/html/draft-peng-v6ops-hbh-05

There is ongoing work to improve the situation.

Bob

---

From: Tom Herbert <[email-masked]>
Date: Thu, 12 Aug 2021 09:29:57 -0700

> There is ongoing work to improve the situation.
And also draft-herbert-6man-eh-limits to improve the situation for EH
in general.

Tom

> Bob
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Bob Hinden <[email-masked]>
Date: Thu, 12 Aug 2021 10:32:43 -0700

> On Aug 12, 2021, at 9:29 AM, Tom Herbert <[email-masked]> wrote:
> 

+1

Bob

---

From: [email-masked]
Date: Thu, 12 Aug 2021 22:43:38 +0200

> on domain edges was also mentioned as core issues.

"Not creating work for routers" seems like a statement indicating a misunderstanding of the purpose of the HBH option. HBH is designed to be an efficient signal to nodes on the path to process a packet that is not destined to it.

With the processing rules in 8200 only nodes explicitly configured to process an option will do so.

The fact is that there are no HBH options defined with Internet wide span. Until there is a real use case for HBH options in the Internet writing more documents about it isn't going to matter very much.

O.