Re: 64share v2

[Ca By <[e-mail]>]

On Tue, Nov 10, 2020 at 10:04 AM <[e-mail]> wrote:

> Cameron,
>
> > > 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.
>
> Excellent!
>
> > 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 ?
>
> The slaac-renum documents describe only a small subset of the problems
> that ephemeral addressing causes.
>
> > 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.
>
> It isn't as much an implementation problem (implementation of this is
> easy) it's the operational problems caused by this (operations in the
> end-user networks).
>

Can you be specific with regards to text in the i-d draft ?



> Is it not irresponsible to specify a mechanism that we know will cause
> massive pain for host stacks, applications etc, if we were to properly fix
> the problem properly, or a miserably functioning network for the end-users
> if we didn't.
>
> Feel free to tell me I'm wrong, and how networks are supposed to work with
> ephemeral addressing.


>
> Best regards,
> Ole