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

Gorry Fairhurst <gorry@erg.abdn.ac.uk> Fri, 05 August 2022 14:47 UTC

Return-Path: <gorry@erg.abdn.ac.uk>
X-Original-To: taps@ietfa.amsl.com
Delivered-To: taps@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4319C159492; Fri, 5 Aug 2022 07:47:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.906
X-Spam-Level:
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 mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KTN6H5kO6H4g; Fri, 5 Aug 2022 07:46:56 -0700 (PDT)
Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [137.50.19.135]) by ietfa.amsl.com (Postfix) with ESMTP id 907BCC159484; Fri, 5 Aug 2022 07:46:54 -0700 (PDT)
Received: from [192.168.1.64] (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id EEC0C1B00137; Fri, 5 Aug 2022 15:46:48 +0100 (BST)
Content-Type: multipart/alternative; boundary="------------YRJsJ7gltUDrl4HtbYlr9bLp"
Message-ID: <4c922ee6-4623-bdee-cc3b-a8ea87cf1fe4@erg.abdn.ac.uk>
Date: Fri, 05 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 <fgont@si6networks.com>, taps@ietf.org
Cc: draft-ietf-taps-interface@ietf.org
References: <9f8de2bc-682e-19c9-a556-3843e106e350@si6networks.com>
From: Gorry Fairhurst <gorry@erg.abdn.ac.uk>
In-Reply-To: <9f8de2bc-682e-19c9-a556-3843e106e350@si6networks.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/taps/MOgqrDnFrOlGApKRy8QOcJtc1OU>
Subject: Re: [Taps] Some comments on draft-ietf-taps-interface
X-BeenThere: taps@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "IETF Transport Services \(TAPS\) Working Group" <taps.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/taps>, <mailto:taps-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/taps/>
List-Post: <mailto:taps@ietf.org>
List-Help: <mailto:taps-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/taps>, <mailto:taps-request@ietf.org?subject=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: 
> https://www.ietf.org/id/draft-gont-v6ops-ipv6-addressing-considerations-02.html 
>
>
> 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,

Gorry