Re: [Taps] Some comments on draft-ietf-taps-interface

Gorry Fairhurst <> Fri, 05 August 2022 14:47 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A4319C159492; Fri, 5 Aug 2022 07:47:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.906
X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id KTN6H5kO6H4g; Fri, 5 Aug 2022 07:46:56 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 907BCC159484; Fri, 5 Aug 2022 07:46:54 -0700 (PDT)
Received: from [] ( []) by (Postfix) with ESMTPSA id EEC0C1B00137; Fri, 5 Aug 2022 15:46:48 +0100 (BST)
Content-Type: multipart/alternative; boundary="------------YRJsJ7gltUDrl4HtbYlr9bLp"
Message-ID: <>
Date: Fri, 5 Aug 2022 15:46:48 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:91.0) Gecko/20100101 Thunderbird/91.11.0
To: Fernando Gont <>,
References: <>
From: Gorry Fairhurst <>
In-Reply-To: <>
Archived-At: <>
Subject: Re: [Taps] Some comments on draft-ietf-taps-interface
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "IETF Transport Services \(TAPS\) Working Group" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 05 Aug 2022 14:47:00 -0000

On 05/08/2022 11:31, Fernando Gont wrote:
>> 6.2.13. Use Temporary Local Address Name: useTemporaryLocalAddress 
>> Type: Preference Default: Avoid for Listeners and Rendezvous
>> Connections. Prefer for other Connections. This property allows the
>> application to express a preference for the use of temporary local
>> addresses, sometimes called "privacy" addresses [RFC8981]. Temporary
>> addresses are generally used to prevent linking connections over time
>> when a stable address, sometimes called "permanent" address, is not
>> needed. There are some caveats to note when specifying this property.
>> First, if an application Requires the use of temporary addresses, the
>> resulting Connection cannot use IPv4, because temporary addresses do
>> not exist in IPv4. Second, temporary local addresses might involve
>> trading off privacy for performance. For instance, temporary
>> addresses can interfere with resumption mechanisms that some
>> protocols rely on to reduce initial latency.
> The terminology employed in this subsection seems a bit confusing, or 
> at least deviates from what we normally use in v6-circles. I suggest 
> taking a look at RFC7721 -- certainly not flawless, but it was 6man's 
> shot to try to agree on terminology. For example, I don't think we use 
> "permanent" and "stable" interchangeably.
> e.g. the "Local" in "useTemporaryLocalAddress" might be misleading to 
> some. -- e.g. could be interpreted as related with link-locals or ULAs.
> Aside, I believe there's much more to dig regarding address properties.
> e.g., we have given it a shot at: 
> e.g., the choice of ipv6 addresses has more than one dimension... and 
> there are tradeoffs involved, which IMHO deserve discussion.
> And aside from the regular address systems normally configure, if one 
> were to specify an API one would probably want to provide a mechanism 
> for apps to be able to request sole/single-use addresses (.e.g., one 
> address per app or container).

I created issue: Temporary Local Address #1053 in github so we don't 
loose this issue,