<snip> > >In relation to draft-ietf-6man-stable-privacy-addresses I remain >unconvinced that it is necessary at all, and oppose its publication.
I think what is proposed is a useful improvement. Note that for publication to happen, rough consensus needs to be reached, not unanimity. >There are 2 well-defined use cases, places where addresses need to be >tracked (like businesses), The problem is that this also allows tracking in the Internet. Business uses want to track devices internally, but would also want to minimise tracking on the Internet. This is the middle ground between existing L2 derived IIDs and RFC4941s. I generally don't agree with the idea of using layer 2 or layer 3 addresses to identify people because I don't think they're tightly coupled enough. However, I still think there is a useful benefit in not exposing globally unique link layer addresses beyond the scope of where they're necessary i.e. on the link itself. Minimising information disclosure is a good security and privacy principle. > and places where they don't. If addresses >need to be tracked, turn off 4941. If they don't, you can turn it on. The other benefit of this approach is that it breaks the coupling between layer 2 interface addresses and layer 3 addresses, such that changing the layer 2 interface would not change the layer 3 address. This has been a common complaint from some server and networking people. While static addressing can easily overcome that issue, it is useful to have defaults that don't create the issue in the first place. My view is that, for devices that don't enable RFC4941 by default, this method should be the new default way of generating IPv6 IIDs. > I >have yet to see a convincing argument for a third use case that would be >covered by the draft, and at this point any changes to the IPv6 spec >need a VERY convincing use case. > I think it always depends on the cost of the changes verses the benefits. In this specific case, the costs of deploying this change are comparatively minor: o it can be deployed in a piecemeal, device by device manner o it only needs to be implemented on devices that care about the privacy of addresses (where RFC4941 are "too private") or those which would benefit from IIDs that are not as tightly coupled to the link-layer interface adresses (typically servers or routers) o it doesn't require any changes to on-the-wire protocols o it can be implemented via user space processes, rather than requiring an OS upgrade, although an OS upgrade is probably preferable One of the fundamental drawbacks of IPv6 is that it was designed in the early to mid 1990s. That was necessary because the primary problem it was dealing with was the running out of IPv4 addresses. Of course other techniques that came along that delayed that problem having a significant effect. However, in the mean time adoption of the Internet as exploded, and a lot of lessons have and are being learned about how it will be both used and abused. Ideally we could stop development and deployment of IPv6, and design and deploy IPv10 with the benefit of both IPv4 and IPv6 hindsight. That is unfortunately impractical, because we finally now need a solution to IPv4 addresses running out, rather than one in 5 to 10 or more years. Incremental improvement rather than radical change (requiring a version bump) to IPv6 is the only choice we have. Regards, Mark. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
