>> 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.
wouldn't a business that require tracking devices internally use DHCP? the DHCP server could use mechanisms similar to what we are discussing for SLAAC, or any other algorithm to create addresses that have properties making them hard to track externally. I also think it is a useful benefit of not exposing link-layer addresses in the IPv6 address. >> 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. even with the mechanisms discussed either the address needs to be stored in persistent storage, or one have to be very careful about the interface-id generation mechanism to make it independent of a change of L2 address. > 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. Fernando is making a good point that these addresses should be the default method even when RFC4941 is enabled by default. the bigger question is how applications and the host stack should behave with regards to all these addresses? should a host that isn't advertising any services even configure a public address? I'm not sure the issue of how applications should deal with the plethora of addresses with varying lifetimes and properties are in the scope of 6man, but it would certainly be interesting to hear the views of someone from the apps area. >> 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 indeed, and you can even argue over the need to standardize something that isn't on-the wire and cannot be tested externally. > 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. hmmm... thats quickly going to become a rat-hole, but I'm not convinced that we would have designed IPv6 very differently if we had done it today. cheers, Ole -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
