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

[Alexandre Petrescu <[e-mail]>]

In IPv4 that person's name is not a problem (the IP address is behind NAT).

Alex


Le 31/10/2018 à 15:37, David Schinazi a écrit :
> Hello Alexandre,
>
> The DNSSD working group is working on privacy-preserving service 
> discovery, to avoid your device name and service list being disclosed 
> to everyone on link. If this is of interest, please join us Thursday 
> afternoon session 1:
> https://datatracker.ietf.org/meeting/103/materials/agenda-103-dnssd-01
>
> That said, this is independent of IPv4/IPv6/IPv6-only-bit. The problem 
> will be solved at the DNSSD layer, not inside IPv4 or IPv6.
>
> David
>
> On Wed, Oct 31, 2018 at 5:50 AM Alexandre Petrescu 
> <[e-mail] <mailto:[e-mail]>> 
> wrote:
>
>
>
>     Le 30/10/2018 à 16:18, Toerless Eckert a écrit :
>>     [...]
>>     I am not aware of any IP protocol version specific optimization options
>>     for mDNS. If there are common ways to make mDNS less chatty without
>>     slowing down discovery, they should be defined independently of the
>>     v6only flag discussion.
>
>     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 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.
>
>     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).
>
>
>
>     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] <mailto:[e-mail]>
>>>     Administrative Requests:https://www.ietf.org/mailman/listinfo/ipv6
>>>     --------------------------------------------------------------------
>>     --------------------------------------------------------------------
>>     IETF IPv6 working group mailing list
>>     [e-mail] <mailto:[e-mail]>
>>     Administrative Requests:https://www.ietf.org/mailman/listinfo/ipv6
>>     --------------------------------------------------------------------
>>
>
>     --------------------------------------------------------------------
>     IETF IPv6 working group mailing list
>     [e-mail] <mailto:[e-mail]>
>     Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>     --------------------------------------------------------------------
>