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 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/taps
