Re: RFC4941bis: consequences of many addresses for the network

[Mark Smith <[e-mail]>]

On Fri, 24 Jan 2020, 00:37 Jared Mauch, <[e-mail]> wrote:

>
>
> > On Jan 23, 2020, at 8:32 AM, Tim Chown <[e-mail]> wrote:
> >
> > The problem statement section in 4941bis is all about user privacy, no
> mention of operational / management complexity, or other “general problems”
> that SLAAC has.  It seems there are unstated problems here :)
>
>
> I would +1 this here.
>
> I would also generally question if rotating IPs is a adequate privacy
> protector considering there are other ways to identify users that are being
> (broadly) employed today.
>

This is the common "it's not perfect, so let's do nothing." Nothing ever
improves if perfect is the only threshold of acceptance. (Nothing is ever
perfect, there are always trade-offs. If you don't think there are
trade-offs, it just means you haven't identified them.)

At the IPv6 layer, we can't do anything about privacy issues at other
layers.

What we can do is improve privacy at the IPv6 layer. That helps reduce the
privacy attack surface. It adds to other measures, and prevents them being
defeated by the IPv6 layer.

Not providing IPv6 address privacy through temporary addresses will mean
people resort to the other address privacy measure they're familiar with,
and the one that makes IPv6 entirely pointless - NAT. Of course, it too
doesn't provide privacy at upper layers.


> The complexity that this introduces into networks for operational
> debugging (provider: what’s your IP address so I can debug? User: Well
> here’s the 20 on the host because I have limited lifetime privacy
> addresses, and I don’t know what outbound one it’s using for this
> connection.  Provider: What’s your IP address so I can debug?  Actually,
> can you just turn off v6 so I can debug your problem?  User: sure, I just
> want it fixed).
>

Anonymity/privacy and unique identity are naturally and will always be in
conflict.

Do we compromise a desire for end-user privacy 100% of the time things are
working correctly for the 0.00...% of the time the end-user is impacted by
a fault?

We have to accept that sometimes an operators' work may be harder than it
could be, and that an end user might suffer for longer in a failure
situation, when under the common case of non-failure situations there are
valuable end-user benefits.

Regards,
Mark.


> - Jared
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>