Re: 64share v2

Ca By <> Tue, 10 November 2020 17:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A73953A0CB7 for <>; Tue, 10 Nov 2020 09:10:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.847
X-Spam-Status: No, score=-1.847 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 6Yp8r_wBJr2J for <>; Tue, 10 Nov 2020 09:10:35 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::d2d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 54AA63A0C8E for <>; Tue, 10 Nov 2020 09:10:35 -0800 (PST)
Received: by with SMTP id u19so15016965ion.3 for <>; Tue, 10 Nov 2020 09:10:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=wQlOHSb1b9HE8HeTbB9JgWguNPAmhLyK3EYn7oln/l8=; b=LCvHHxGlFFWIAdRUaA7//xjB1mBnzyU1gtbf0n7p562we96CS0IzkNzeqhkuoRnf42 JpM43VU24Q3oR4ow+zZAKnLeaALZlgbAR6EoDlfJOu7W6rUaYWdRKIMcborPLlwTIcLW xMran2e8+bndzlXiseF30fZolZ/JeBullMPAU6MbWe9dUhq7vs+OLq6nVkCAKkTq+pSa I8pr9Z9y39Yv2VwwaIc1rn/fF1gc2gRw0cTGarOjS5k/K1bpGMGM6xNDffePkMbOOLTg UON0HIdLo9rBfc05HlUzyVC7amjJ2CwNhVvj6vstE3ojms9U0Hhl7PdqbwZr/8ZieXZz Cz7Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=wQlOHSb1b9HE8HeTbB9JgWguNPAmhLyK3EYn7oln/l8=; b=iT00kru4ab4mEF6hGVvGW51UKvQd/xfSmyzaFIGx3DdrT1Q2HWRHtJ+OrIcGTpLbPd 1yesAxJHg/9daPtRJ3j/Xd0UQ/8isS98h79OxM1nZgGFyKT+j0opR194vjQZ9wSsAODm fTkgGEGnBb3g5MXUIlxe1cW1prWH5gQDAG0xslpbJBabvOojJBinZFA9CXK2+Fo2x/FR 5HtSL3j8S6L47kQKm0I6Q+QytXYiXI8a0DJQjZB+cJ0tefoKu4U4svy3BddeGmQhdup3 ACJc1hvvIMBDANyQn55+Vz8duf6Gd2WVrq13sy/Vjk2tpCS3miN2o20mw1YxxxtZ11Rx xenw==
X-Gm-Message-State: AOAM531Z93JwJQqxC4sPBX6/NXy8cHsHmvflMRbQFRGr6BNjLSmDMmci pidVuWjgmMmScqkUIR/Uc/z7QhXTU5RhYZ815M9siM1y3moPWw==
X-Google-Smtp-Source: ABdhPJyvefEs1WpabJpOIm9AJYCdF8NTR+CkdNpzO63BVqBy+gBSEeRL9Eksdk+ICHJxRcCl4k0cCMd7NQ7RhtrFrNw=
X-Received: by 2002:a5d:9813:: with SMTP id a19mr15218233iol.194.1605028234569; Tue, 10 Nov 2020 09:10:34 -0800 (PST)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Ca By <>
Date: Tue, 10 Nov 2020 09:10:23 -0800
Message-ID: <>
Subject: Re: 64share v2
To: Ole Troan <>, Ipv <>
Content-Type: multipart/alternative; boundary="000000000000c6ab9b05b3c3c18e"
Archived-At: <>
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 10 Nov 2020 17:10:37 -0000

On Tue, Nov 10, 2020 at 8:53 AM <> wrote:

> > From what the operators have said, using the existing infrastructure for
> RA/SLAAC is important.  They have not needed DHCPv6.  So they want to be
> able to offer this using the tools they have deployed.  That seems
> reasonable to me.  Creating a new protocol for this would seem even worse.
> Then you must have missed the point I made earlier.
> What operators find attractive about the RA hack is a deployment model
> where the user's delegated prefix is taken out of a dynamic pool local to
> the box.
> That deployment model results in ephemeral addresses. Which might work in
> an environment with tethering today (a client-only stub network, where user
> is expected to press refresh often). But it is not obvious how scaling that
> hack to multiple links/routers is possible. Without a massive cost to the
> rest of the ecosystem.

Your understanding is correct.

I believe this thread saw several reports that prefixes in the home are
commonly ephemeral, sometimes on purpose, so this is not new .  It is also
consistent to my user experience with multiple large USA broadband
providers.  Reports from around the world confirm similar, see
Do you believe there is a new risk here that is not yet commonly seen ?

If you would like to provide some brief cautionary text for the I-D, I
would be happy to include it, so that implementers are not under any false
impressions.  Perhaps reference to draft-ietf-v6ops-slaac-renum-05   would
be sufficient.  That said, like many I-Ds, this one has trade-offs.

> We already have a protocol so no need for a new one.
Your opinion has been noted.


> Cheers,
> Ole
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> Administrative Requests:
> --------------------------------------------------------------------