Hosnieh Rafiee wrote: >>> In corporate environments it is very important that cross-correlation >>> of log events can occur to support various operational processes (also >>> over longer periods of time and for examining historical records). >>> IPv4 did not randomly rotate end node identifiers in an uncorrelated >>> manner, and the consequences of this new behaviour could be far > reaching. >> Well, I think the jury is out on use of 4941 in enterprise environments. > There >> are advantages and disadvantages. Accountability is still manageable. >> >> But in general I agree with Ray's points. >> > > If the monitoring is the key role in your network and you have access to the > inside of your whole network, the question is why you sacrifice your users > privacy by having the same IID forever in the same network? You can use a > monitoring system where log the MAC and IP addresses of the pcs. If the IP > addresses changes, you can still monitor them based on their MAC and log > this new IP address for this computer for further usage or any new events > and keep this log for a certain period of time. > > Thanks for your comments. > Regards, > Hosnieh > >
I think you greatly underestimate and trivialise the proliferation of operational processes and systems that use an IP address as a node identifier and as a key to other data, and that rely on it being largely time invariant/ stable (at the very least for a decent caching interval so that it doesn't have to be resolved for every inbound packet/connection being processed, or for the time that the machine is switched on). I think that risk is well worth noting in your draft. You only have to look at something like ~/.ssh/known_hosts, where a flat file uses an IP address to associate a server with a public key, to see how widespread this practice is. If you want it to stop this practice 1) it's going to be a long and painful process 2) you'll probably need to provide a viable alternative source for node identifiers and/or user identifiers. Otherwise if something like my SSH server process decides to time cycle it's IP address and dynamically update DNS due to a lifetime timing out 1) it is likely that every single long-lived remote SSH session will be broken at some point, 2) upon reconnection to the new server address registered in DNS, all users will likely be asked to relearn/reconfirm the trust relationship with the server. That trust association can't be trivially repaired for an automatic/cron process without an alternative trusted source of node identifier. This is just one of a myriad of examples. regards, RayH -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
