Re: Running code - IPv6 mDNS MacBook Pro privacy (Was: I-D Action: draft-ietf-6man-ipv6only-flag-03.txt)

[Toerless Eckert <[e-mail]>]

On Wed, Oct 31, 2018 at 01:49:45PM +0100, Alexandre Petrescu wrote:
> True.  I think the IPv6 version of mDNS is probable more chatty than the
> IPv4 version, in some cases.  But even then, removing the IPv4 mDNS could
> only save battery, compared to IPv4+IPv6 versions of mDNS.

As said, i am more interested in getting rid of IPv4 on dual stack
capable hosts to simplify device operations, host stacks, diagnostics, etc.
And because link-local-scope IPv4 sucks (because of IPv4).

Lower power consumptions is cool, but a more constrained use case right now
(would become a lot more important i hope in the future though).

> As a side note, it is possible to improve other aspects of the IPv6 version
> of mDNS only and not care about the IPv4 version.  One could ask Apple to
> make an improvement for the IPv6 version of mDNS with respect to privacy:
> stop putting the MacBook Pro owner's name in the mDNS request, because
> anybody on the link can see it and attach it to the global address.

I always liked the notion of trusted, private networks where you can be
open and friendly and everybody can know you. Which i guess is the
history of appletalk networks, at least in the 90th. On todays home networks
where you have uncounted embedded devices from companies that all try to
improve their margins by abusing your data that notion went down the
drain *sigh*. 

> One would not ask Apple to do that for IPv4, because IPv4 is not worth the
> effort, and because there is no privacy risk there (the IP address is behind
> NAT).

See above. I am sure my printers with cloud-print functionality are
listening to all mDNS multicasts and report the names of other devices on the LAN
to the printer vendors cloud service.

Would be great if there could be trusted third parties vetting companies
and handing out certifies to only those devices that will not enable
spying on you. think today it would be very simple to start such a
service. It would just not be able to hand out any certificates *sigh*.

Cheers
    Toerless

> Alex
> 
> > 
> > Confounding the situation like you propoose is like "make ipv4 service
> > discovery less chatty to a point that it may break because it doesn't
> > matter if ipv6 is running" - and thats not a correct approach given how
> > the service in question may be ipv4 only.
> > 
> > There may be optimization options to prefer IPv6 over IPv4 discovery
> > for dual-stack cases, maybe there is something already defined, but
> > that could only be IMHO through timing - e.g.: look for service
> > first via IPv6 and only try IPv4 adfter some short timeout. But that
> > too would better be defined independently of the ipv6only flag
> > discussion because its IMHO useful independent of the flag.
> > 
> > Cheers
> >      Toerless
> > 
> > > --------------------------------------------------------------------
> > > IETF IPv6 working group mailing list
> > > [e-mail]
> > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > > --------------------------------------------------------------------
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > [e-mail]
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------
> >