关于slaac泄漏机器mac地址的风险问题

这个问题不好回答。
对于个人来说，泄漏MAC地址会导致什么样的结果，取决于要窃取你信息的人的专业知识，以及所拥有的资源。除非在多个网站上主动泄漏自己的MAC地址，否则至少通过搜索引擎是无法追踪到你的。至于“隐患”多大，取决于你对个人隐私的看法。
而对于物联网设备来说，由于这一特征是周知的事实，提供商不可能不采取对策。
一些操作系统，比如Windows有相应的隐私策略，会把额外获取的临时IPv6地址（不泄露硬件特征的）作为首选。
光猫下再接一个支持IPv6的路由器的话，也要看路由器以什么样的方式获得和分配IPv6地址。光猫拨号的话，路由器是pass through还是prefix delegation；路由器拨号的话，是有状态还是无状态。
我个人认为，这个并不是问题。实际上很多人都希望获得固定前缀，而不是现在的随机前缀。这是比起泄漏硬件特征的IPv6后缀更容易追踪到个人的。而在一些需要管控的应用场景里面，有硬件特征的IPv6后缀可能更便于管理。

mac地址只是网卡地址而已，别人知道了也不会有什么影响，顶多就是知道你的网卡厂商是哪家被害妄想症？
不放心可以打开这个

看来你对这个问题比较关心，那我也尝试深入一下。
* 以下内容基于个人的理解，如有不恰当的表现敬请谅解 *
先看一下IPv6地址的构造：

一般把前48bits的全球路由前缀和16bits的子网标识统称为“前缀（prefix）”，后64bits接口标识成为“后缀（suffix）”。
该格式最初由RFC 2373规范，随后是RFC 3513，RFC 4291。同文档还规范了自动生成接口标识时，使用EUI-64格式。
具体方法如下：

①把48bits的MAC地址分割成2个24bits
②在中间插入16bits的FFFE
③转换为二进制，将其第七位反转（0→1，1→0）
④转回十六进制，即为接口标识
由此可见，使用EUI-64生成的接口标识（IPv6地址后缀）可以轻易地被反推成MAC地址。
而这个格式也被规范到后来的RFC 4862《IPv6无状态地址自动配置（IPv6 Stateless Address Autoconfiguration，SLAAC）》中。
为此，另外规范了RFC 4941《IPv6中无状态地址自动配置的隐私扩展（Privacy Extensions for Stateless Address Autoconfiguration in IPv6）》。内容为使用EUI-64格式自动生成的同时，再生成一个随机的接口标识。该地址生命周期较短，并优先作为发起连接时的源地址，以降低暴露硬件特征的风险。
Windows XP以后，Mac OS X 10.7以后，iOS 4.3以后，以及Android 4.0以后均支持并默认开启IPv6隐私扩展。
但RFC 4941的隐私扩展实际上只是治标而不治本，因为仍然会自动生成带有硬件特征的接口标识，只是不把它作为首选的通信地址。为此提出解决方案的是RFC 7217《A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC) 》，该文档规范了一种新的接口标识自动生成的计算方法（称为"Semantically Opaque IID"，即语义不透明的IID），兼顾了隐私性和管理性。（具体算法不赘述）
或许你所说的“混淆”指的就是语义不透明的IID。
但这个并不是取决于光猫/路由器，而是由客户端的操作系统生成的。
以下是部分操作系统在生成接口标识时所使用的的规范：

* Windows使用的是微软独自的"Fixed IID"，具体生成方法未确认。
最后再补充一下我的观点。
确实不使用隐私扩展和语义不透明IID的话，任何通信对手都可以轻松地得知你的MAC地址。
但正如我前面所说，即使泄漏了MAC地址，对方能做的事情也相当有限，因为通过MAC地址攻击或追踪个人所需要的成本太大。
纵然EUI-64的IID是个风险隐患，但我个人认为造成实质损害的可能性非常低。

补图：

①把48bits的MAC地址分割成2个24bits
②在中间插入16bits的FFFE
③转换为二进制，将其第七位反转（0→1，1→0）
④转回十六进制，即为接口标识

写个脚本，每天自动更换MAC……