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

Fernando Gont <fgont@si6networks.com> Fri, 05 August 2022 10:31 UTC

Return-Path: <fgont@si6networks.com>
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 34340C14F73F; Fri, 5 Aug 2022 03:31:20 -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, RCVD_IN_ZEN_BLOCKED_OPENDNS=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 rQNl1F-gxVnt; Fri, 5 Aug 2022 03:31:16 -0700 (PDT)
Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FCC5C14F72F; Fri, 5 Aug 2022 03:31:16 -0700 (PDT)
Received: from [IPV6:2001:67c:27e4:c::1001] (unknown [IPv6:2001:67c:27e4:c::1001]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 3755C280261; Fri, 5 Aug 2022 10:31:11 +0000 (UTC)
Message-ID: <9f8de2bc-682e-19c9-a556-3843e106e350@si6networks.com>
Date: Fri, 05 Aug 2022 07:31:10 -0300
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.1
Content-Language: en-US
To: taps@ietf.org
Cc: draft-ietf-taps-interface@ietf.org
From: Fernando Gont <fgont@si6networks.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/taps/L5dgkXVXHZM2XeuY8F-CKPORKDw>
Subject: [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 10:31:20 -0000

Folks,

Some comments on this particular bit:

> 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).

Thoughts?

Thanks!

Regards,
-- 
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com
PGP Fingerprint: F242 FF0E A804 AF81 EB10 2F07 7CA1 321D 663B B494