Re: [tsvwg] New Version Notification for draft-daiya-tsvwg-udp-options-protocol-number-00.txt

Tom Herbert <> Sun, 23 July 2023 17:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A00AEC14CE54 for <>; Sun, 23 Jul 2023 10:02:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.096
X-Spam-Status: No, score=-7.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=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 IzQat2iLGJU5 for <>; Sun, 23 Jul 2023 10:02:50 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::534]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by (Postfix) with ESMTPS id 5710CC14CEFE for <>; Sun, 23 Jul 2023 10:02:16 -0700 (PDT)
Received: by with SMTP id 41be03b00d2f7-5577900c06bso2631233a12.2 for <>; Sun, 23 Jul 2023 10:02:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; t=1690131735; x=1690736535; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=sJToI2tTpOHJB2W8O6rBMBJVAc+dN1femIXTwADzR14=; b=aVx53D/OILqzFw38w0pD9RYgy1Q0KIhup1I0dc/SwbpskAzIiuZwdkDzWKzuSH5vaB 8cECLKp7d0eeJuWFsrcMEsvPlNjNrKYZLLM0QhBcaNYLFSh6NAnkND4Lb90S0e3EbUbO ohqZaxmAS1WUqmH5A5QOcH9a9jsvpYKkMOPnfXoFXFR38Cf4XSbjNX76muOyU09qrc1d dlRestW73G/Wme/WlTWjVz0NwQ+DnM8NLqS96/1A59Is1NtQ4PV+Lk5SBxi+oiFwYpOO MKfFnZhMQR5hGJs4Ob2kAIu6CVaDKbfsD4XZ3kxN1KrN63Nq6MYmFsNYPxBd8m3vVwk4 oFcw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20221208; t=1690131735; x=1690736535; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=sJToI2tTpOHJB2W8O6rBMBJVAc+dN1femIXTwADzR14=; b=dvFb9wowannJHY/t4OMrbFB7jC9mLBO9I4OYDXrPBiX0OaxrLJFKSgvXq/DhGjZj5b XCg5E2B5ubs92wUpznU7Ro9zz4s7K1xgjx9d5uGPCt5/U141i7IQ7k7E8des/ZbN+Ey3 //DTBPuhNSXVwATkHZA8QEe6Om+08Tm7vh+YalzO3VdQK3NV3RF55F4nb62oyVllAIhz 8QOtYFXJzlcU0opsVgl77dVaX1nDRSRYOZ3vbqd5Z2q0lhqo/oi3e6d2ZttQRSrq8akw auOIvvT77WqP+gbVZsDfI+RiGANHgELPgU63YPOe0aXL58l68kk7suHcKbcbz1uMxAGt vh+A==
X-Gm-Message-State: ABy/qLZSFNtgRYqcox3oy5rj0rv/Khbcyf5hlS0f9rGCrVG/fMM3v18+ M+GAySahf0nX/+b2iSYj8bn6KwR16fU0ZfDPNem0hg==
X-Google-Smtp-Source: APBJJlEvszNdubNF+2ihTrrfr8VkHr/Z+StqIvihJTr1rwMWnKh2wxx/lMZUFLLKcASWnlgaEYaZtFuUunzQFtpYBbo=
X-Received: by 2002:a17:90a:7b81:b0:268:1dd3:695e with SMTP id z1-20020a17090a7b8100b002681dd3695emr169151pjc.49.1690131735376; Sun, 23 Jul 2023 10:02:15 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Tom Herbert <>
Date: Sun, 23 Jul 2023 10:02:02 -0700
Message-ID: <>
To: Joe Touch <>
Cc: Yoshifumi Nishida <>, Gorry Fairhurst <>, Daiya Yuyama <>, tsvwg <>
Content-Type: multipart/alternative; boundary="000000000000b60ea906012a75e2"
Archived-At: <>
Subject: Re: [tsvwg] New Version Notification for draft-daiya-tsvwg-udp-options-protocol-number-00.txt
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Transport Area Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 23 Jul 2023 17:02:54 -0000

On Sat, Jul 22, 2023, 8:30 PM <>

> On Jul 20, 2023, at 7:35 AM, Tom Herbert <tom=
>> wrote:
> Hi Daiya-san,
> Many people don't want middleboxes meddling with *anything* beyond the
> network layer!
> Besides that I'm not sure this is feasible, it would require
> middleboxes to process trailers which is not amenable to efficient
> implementation for a high performance implementation. Also, this type
> of marking could only be used with UDP and doesn't help with other
> protocols. You might want to look at
> draft-cc-v6ops-wlcg-flow-label-marking, it's a more generic solution
> that would work with any transport protocol.
> Tom
> If I understand what Daiya-san is trying to accomplish, this would be a
> step backwards.
> The problem is exemplified by netconf; there are 5 different assignments:
> over SSH
> over BEEP
> over SOAP over HTTPS
> over SOAP over BEEP
> over TLS
> The goal is to have a field in a transport header that indicates the next
> protocol, not the entire rest of the protocol stack, e.g., that would allow
> “next protocol” headers to continue to be chained through the transport
> layer. This would be useful for TCP, UDP, and SCTP. I don’t know an
> equivalent capability is already possible in SCTP, but in TCP it is very
> similar to the “service name option” draft of mine from years ago.
> The new proposed doc adds this to UDP - though, AFACIT, the service name
> option would work there just as well.
> AFAICT the bigger issue is that there’s no way to continue the chain past
> the transport protocol - other protocols don’t universally include a “next
> protocol” field.

That is commonly accomplished by encapsulation and an Upper Layer Protocol
(ULP) header-- like VXLAN, GRE/UDP, various RPC headers, ULP multiplexing
in HTTP 2.0, etc. The advantage of this approach is that the protocol
number that describes the transport payload is part of the payload, and as
Christian pointed out, this is especially important where the payload is
encrypted and we want to avoid unnecessarily leaking information about the
encrypted data.

> However, trying to use a field the IP header for this purpose goes in the
> wrong direction. The point is to create a chain as long as the number of
> layers of protocol and to put that chain inside the protocol layers, not to
> pull them all out to the IP layer flow label (which would not chain).

In the use case I mentioned, the information is purposely being exposed to
intermediate nodes in the network. The only proper way to do that is via
HBH Options (overloading the flow label with this information as proposed
is okay for an experiment, but I don't believe that could be


> Joe