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
- [Taps] Some comments on draft-ietf-taps-interface Fernando Gont
- Re: [Taps] Some comments on draft-ietf-taps-inter… Gorry Fairhurst