Re: 64share v2

On Tue, Nov 10, 2020 at 8:53 AM <otroan@employees.org> 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.
>
>
Ole,

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
draft-ietf-v6ops-slaac-renum-05.
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.

CB

> Cheers,
> Ole
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>