<p dir="ltr">Love it</p>
<div class="gmail_quote">---------- Mensaje reenviado ----------<br>De: Fernando Gont <<a href="mailto:fgont@si6networks.com">fgont@si6networks.com</a>><br>Fecha: 6/4/2016 9:21<br>Asunto: Re: Discussion of default-iids and MAC address randomization and RFC4941<br>Para: Lorenzo Colitti <<a href="mailto:lorenzo@google.com">lorenzo@google.com</a>><br>Cc: <<a href="mailto:draft-ietf-6man-default-iids@tools.ietf.org">draft-ietf-6man-default-iids@tools.ietf.org</a>>, Chairs 6man <<a href="mailto:6man-chairs@tools.ietf.org">6man-chairs@tools.ietf.org</a>>, "<a href="mailto:6man@ietf.org">6man@ietf.org</a>" <<a href="mailto:6man@ietf.org">6man@ietf.org</a>><br><br type="attribution"><p dir="ltr"><br>
El 6/4/2016 9:02, "Lorenzo Colitti" <<a href="mailto:lorenzo@google.com" target="_blank">lorenzo@google.com</a>> escribió:<br>
><br>
> Fernando,<br>
><br>
> going on the record now because I won't be in BA.<br>
><br>
> On Wed, Apr 6, 2016 at 8:23 PM, Fernando Gont <<a href="mailto:fernando@gont.com.ar" target="_blank">fernando@gont.com.ar</a>> wrote:<br>
>><br>
>> * Stable addresses are currently required<br>
><br>
><br>
> As should be clear by now, I disagree.<br>
><br>
> Further, I think that unless that statement is heavily qualified and applied only to specific use cases, there will need to be a substantial privacy debate explaining how, even though "pervasive monitoring is an attack", we are mandating that the IPv6 addresses on a given network be stable for the life of the device. I think other parts of the IETF will need to be involved in that debate as well.<br></p>
<p dir="ltr">Please check the slides I've attached. Stable addresses are not a requirement of this document, but a requirement of existing specs.</p>
<p dir="ltr">This docunent applies *when* generqting stable addresses which, nowadays, is always. If you don't want that, you keed to update rfc4941, or randomize mac addresses and use the randomized mac address as the net_iface parameter of RFC7217.<br><br></p>
<p dir="ltr">>> *  It's important that the implications around randomized MAC addresses<br>
>> when used with traditional SLAAC be clearly spelled out (see the posted<br>
>> slideware).<br>
><br>
><br>
> There's a lot of FUD in that:<br>
> We do not control whether MAC addr randomization algorithm is appropriate or if it is actually possible. Not true - or rather, it's mostly not true. The exact level of incorrectness depends on who "we" is. If "we" = "Apple", then that statement is completely false. If "we" = "Windows" or "we" = "Android" then it is only mostly false. If "we" = "Linux" it is almost certainly false unless the host is using binary-only drivers.</p>
<p dir="ltr">We == ietf. This is not an android or mac devloping forum.<br></p>
<p dir="ltr">> Wastes 18 bits of entropy: "wastes" how? What's the downside?</p>
<p dir="ltr">Local/global bit, unicast/multicast bit, and 0xfffe. Talk to JC Zuñiga.<br><br></p>
<p dir="ltr">> Interoperability problems: depends heavily on the link layer. It's not true that you can't recover from DAD failures using SLAAC, you can just pick another number and try again.<br>
> Of course, there's nothing new in my position, just like there's nothing new in yours. I'd just like to make sure that nobody can later state that the people who objected to the document are no longer objecting :-)<br>
><br>
> Cheers,<br>
> Lorenzo</p>
</div>