Re: [v6ops] Are we competitive?

Tom Herbert <tom@herbertland.com> Fri, 19 August 2022 23:57 UTC

Return-Path: <tom@herbertland.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A007EC1524B9 for <v6ops@ietfa.amsl.com>; Fri, 19 Aug 2022 16:57:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.896
X-Spam-Level:
X-Spam-Status: No, score=-6.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20210112.gappssmtp.com
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 HBA0xsKRjbOV for <v6ops@ietfa.amsl.com>; Fri, 19 Aug 2022 16:57:58 -0700 (PDT)
Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com [IPv6:2a00:1450:4864:20::12a]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 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 BC0D4C14F75F for <v6ops@ietf.org>; Fri, 19 Aug 2022 16:57:58 -0700 (PDT)
Received: by mail-lf1-x12a.google.com with SMTP id l1so7484315lfk.8 for <v6ops@ietf.org>; Fri, 19 Aug 2022 16:57:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20210112.gappssmtp.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc; bh=YqnmYToeotCbcSppn249BxBzm6ILCAfaQlUzI+oeF6k=; b=vHhpHtXoe30sOGDCKic7vCR5pp+CsBWKPhwyZVFx4odXl/HpAaJbDLy+NYOqBQkj07 +1ciKqtcwWUbtkzf+edpepWaoTwO4yb7cYH4JnlayXl4+b5h03Gh9OymIOZtbSEp3vkY 5eMCGgJHfq0mUa/iqnD0wtjnOuT7gLMh/s33pcHPze/jlHd5Q4NcWlw+fgNsNlfVbNiD nSUJsaq3L8l4vzBzF/IObSqDmqg6VAPNDgKdGgYWPNedDH+swGQwSnQwn3gOnYS9pGcD xqgS/GUQRyTBf1YpYaGW4rhPVXJffSrvfXbjYWCCJibsGHaTQrhGj+SVa07mWaLD8VqT E6zw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc; bh=YqnmYToeotCbcSppn249BxBzm6ILCAfaQlUzI+oeF6k=; b=K28bqp3IFerfbzfZtZvvbZbppFEeAmt9PUgldbQS6s0+jJS4/2yeARqwCX4oTYwiOz WfG+wl4BcoLIVjflPQwcSV9jLp3uu3bm7O+EMswFIvrGw08fvKGnyTNvL1OSzd0QS8vy Hvqr4VKh3mkykJR3px/Mfzj95VLnMJ1eIkiMV6ifHtRgn5/L0dK16kcZsP2OAih87AWc dTPVVF5XzPP2G5D2wPLO9zhk5LQS0wWlxPnJaq768kEsTqzgjWVT4HQvduui/9G9oNdW 4uYcjGR+V0fyp+EhIoFLH0j1iu+S6Z0WxCyLHzlmoJ1s2zepEaIuf5Jx9G0s1rPUy76p Zwrw==
X-Gm-Message-State: ACgBeo1MFZrEyzwElV3E3T2I2ioJ6h6yk58xI8aJCnWXgYHuGj3rcxR2 XspewLnptrvfrgPrdyNadX5kEc0TWKup/zL2y4RoAw==
X-Google-Smtp-Source: AA6agR6z0eCIje801fNNop2cPZ06Kze5TuVIBFXvS018ijOfBBnrqxYVlyT9nXNskQfRDr2Xak6iqK8aJjaAkvX8kWI=
X-Received: by 2002:a05:6512:2523:b0:48a:f4e9:378c with SMTP id be35-20020a056512252300b0048af4e9378cmr3003979lfb.680.1660953476422; Fri, 19 Aug 2022 16:57:56 -0700 (PDT)
MIME-Version: 1.0
References: <3f138b03-940a-e83a-6c6e-6039506b6e4b@gont.com.ar> <10f89b7cbe784881bd22b4af81577aa6@huawei.com> <CAN-Dau0nz0TouDnz5pei0MCmTzSbP8q+gHLx1m0sxX0hsuPX3w@mail.gmail.com> <b9f33aa499b043bb90ff926731db9739@huawei.com> <b885bdd4-d837-1eda-9614-36c76190d920@gont.com.ar> <a6975472445f49018abab153fa61b399@huawei.com> <YvoaJ+IJdl/VXYLj@Space.Net> <1cdf7569a11d43e2b4fdd8675b657e42@huawei.com> <YvoilaQfj40uYI5X@Space.Net> <2e465d49-7636-1a09-0b0a-1616c3840bb8@gmail.com> <YvolSM4c05Hu2YAn@Space.Net> <3ea43ae8-a88e-8d44-1b21-7b66f3924980@gmail.com> <9B8691E8-AD21-4A87-8735-DEBE4E0CDCED@gmail.com> <bc72f01f-5c24-b738-5bab-5c48282e0523@gont.com.ar>
In-Reply-To: <bc72f01f-5c24-b738-5bab-5c48282e0523@gont.com.ar>
From: Tom Herbert <tom@herbertland.com>
Date: Fri, 19 Aug 2022 16:57:44 -0700
Message-ID: <CALx6S37Xc-QAARizWgcN9LXr8xDGmO0mqVCe2Dc5PV9K=1pRww@mail.gmail.com>
To: Fernando Gont <fernando@gont.com.ar>
Cc: Fred Baker <fredbaker.ietf@gmail.com>, "Soni They/Them L." <fakedme+ipv6@gmail.com>, IPv6 Operations <v6ops@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/nFOE9sEoLYUkDF-HzJ50TO4XXoo>
Subject: Re: [v6ops] Are we competitive?
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 19 Aug 2022 23:57:59 -0000

On Fri, Aug 19, 2022 at 3:58 PM Fernando Gont <fernando@gont.com.ar> wrote:
>
> Hi, Fred,
>
> On 19/8/22 16:09, Fred Baker wrote:
> >
> >
> >> On Aug 15, 2022, at 9:07 AM, Soni They/Them L.
> >> <fakedme+ipv6@gmail.com> wrote:
> >>
> >> We do not like it when IPv6 enables cross-website tracking in spite
> >> of browser-based protections, including the ability to separately
> >> identify household/community participants, which would be entirely
> >> avoidable if the IPv6 stack had full built-in support for ephemeral
> >> addresses and browsers used them per-tab or so.
> >
> >
> > I'm going to ask the obvious question. What is the difference between
> > an "ephemeral" address and a "temporary" address? I think you're
> > asking for a temporary address that is used for a specific purpose (a
> > tab, a tcp session, whatever) and then forgotten.
>
> Answer is in Section 4.4 of
> draft-gont-v6ops-ipv6-addressing-considerations-02:
> https://www.ietf.org/archive/id/draft-gont-v6ops-ipv6-addressing-considerations-02.html#name-address-stability-considera
> ;-)
>
> TL;DR; They are addresses that are used by a single application (e.g., a
> web broswer) or even a single site or application inside the browser.
> Otherwise, temporary addresses would still allow correlation while the
> same address is in use (while the address is preferred).
>
> Strictly speaking, temporary addresses *are* ephemeral (i.e., they are
> certainly not constant or stable). But there are cases where you'd
> probably want an application to be able to request a
> single/exclusive-use address.

Fernando,

Assigning a unique pseudo randomized IP address as the local end point
of each TCP connection would provide the strongest privacy guarantees
in terms of preventing cross correlations between different flows from
the same source. In this model, the addresses are more aptly described
as ephemeral and not temporary. The address would be used for the
lifetime of only a single flow which could be an arbitrarily long
period of time. Only when the connection is terminated is the address
released back into the pool. This does mean that at a given point of
time a host may have thousands of such addresses in use, but I believe
that's mostly a problem of managing bulk address assignments and
network forwarding via identifier to locator mappings.

Tom

>
> Thanks,
> --
> Fernando Gont
> e-mail: fernando@gont.com.ar
> PGP Fingerprint: 7F7F 686D 8AC9 3319 EEAD C1C8 D1D5 4B94 E301 6F01
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops