Re: [tsvwg] Rregarding soft-state and UDP options

Tom Herbert <> Sun, 05 January 2020 21:17 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 15D56120154 for <>; Sun, 5 Jan 2020 13:17:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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 0pShOsnLBifx for <>; Sun, 5 Jan 2020 13:17:52 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::536]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 781ED120110 for <>; Sun, 5 Jan 2020 13:17:52 -0800 (PST)
Received: by with SMTP id bx28so45901318edb.11 for <>; Sun, 05 Jan 2020 13:17:52 -0800 (PST)
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:content-transfer-encoding; bh=LnTkjbHxH95RTNKj/qUSuVw+vExK9dMxHIJUbQ0xzs8=; b=vVjM9ZLOVcOVVVm0qOWZv8Apq2COvwGRF7mEUZWe4OryGLK6v8mvrrhph0XqD6miQt y1haXuzpN55idU9Zt+79vh1V4nOTwFF8yVgIdJZTU+/PZ3xHkBgCbr5yyO5WhtksyWsr bzpp9R3V+2WxTx4ywfnASHRgKTFJl7eAhQQ3YbQNN3viG9bF8MWYnhX3zFa7YfakGAXV VQnynssgMlwBttp7Lg1Cyonari1Ul3LfmdIlRnwnUrag1QIf3FYh5dR6+6cHcetY31yz 4k/jFxG1BHx0kh3QGfhuVZVNRLl0YdxhkrVzz3CpmnJ7uQlrd9uYWq1e57Rgh7G9alKa p1lg==
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:content-transfer-encoding; bh=LnTkjbHxH95RTNKj/qUSuVw+vExK9dMxHIJUbQ0xzs8=; b=N7ZvGtM0atx7gVOUV17v89Db+IU7VR5cPNr5tl7ptyJXwF1PkXynt2kkjVEGMUo5zy OLUwxl+ijaBIY841JlzLtmyGAVLSXNCkdmFo2uOk6Hv7BgNda6M9r0lPVsdP1Kj1dEe1 OwGj+sIYTGd3/12Me9sUGO+Et3UX9oWaJWk+xnDj2v6kUhQvR9M4DwbFeI3NyMwFBgWy CACtaAxC5lfHCkbVgXtqboqdwOxj3wU+kodC9N6IsybgQV7FApvFosSHG94KdnGCOqkl 4Mm1cpVWJZXt0FsAuET+MvOppg+oTX1w4Qz/v6nxzfu3oKl5GzN8tjkgMqu1J2PnrDCz B78Q==
X-Gm-Message-State: APjAAAXl0GCZbyATalmw7zdKKZoX4uVo8gRpVx022dB8v0GHdG9amFmT U739nvio8OFQeL45S6BPsVmE+Fr39q0WUVFP168jcQ==
X-Google-Smtp-Source: APXvYqyZguA/Q6t6TgbGeTcFHX++vJ6IUpbzsJQrfB76C5IjAa0db3U3KTp11KG0tUCkdjz4+apoyFRBigTed497Lck=
X-Received: by 2002:a17:906:9615:: with SMTP id s21mr105083381ejx.20.1578259070822; Sun, 05 Jan 2020 13:17:50 -0800 (PST)
MIME-Version: 1.0
References: <> <> <> <>
In-Reply-To: <>
From: Tom Herbert <>
Date: Sun, 05 Jan 2020 13:17:39 -0800
Message-ID: <>
To: Joe Touch <>
Cc: TSVWG <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [tsvwg] Rregarding soft-state and UDP options
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 05 Jan 2020 21:17:56 -0000

> You keep citing network protocols, not transport.
Because, just like UDP, IPv6 is a stateless, connectionless, datagram
protocol that works over unicast, multicast, anycast, and broadcast.
They have all the same pertinent properties. If you know of a
transport protocol with options having these same properties then we
can look at that (note, that protocol is not TCP!).

> Transport protocols don’t have this behavior - and it’s IMPOSSIBLE to implement for legacy UDP receivers.
It's not impossible, I've already suggested the necessary text and
requirements to prevent a receiver from incorrectly processing an
unknown options that cannot be ignored. I claim that this protocol
works for all use cases of UDP in order to satisfy the requirement the
requirement. If you dispute this claim, then please provide the exact
scenario where you think it fails. Here again are the requirements to

Options that cannot be ignored by a receiver due to side effects or
other requirements MAY be sent. An option that cannot be ignored is
indicated by the high order of the option type being set to 1 (if the
high order bit of the option type is 0 then the option can be safely

If an option that cannot be ignored is received by a node that does
not recognize the option then the packet MUST be dropped. The
following requirements ensure this:

  - Options that cannot be ignored MUST NOT be sent in packets that do
not use FRAG+LITE format. This prevents a legacy receiver from
incorrectly ignoring an unknown option.
  - If an option is received with the high order bit of the bit of the
option type set to 1 and the receiver does not recognize the option,
then the packet MUST be dropped. This covers the case where a receiver
that processes UDP options however doesn't support a particular
received option that cannot be ignored.