In your previous mail you wrote:
As for your comment about IPv6, I'm afraid we have similar issues
=> no, in IPv6 we have RFC 4941 and the point of control is not
at the same place (i.e., nobody trusts ISPs to protect privacy :-).
Med: This is not the point. RFC4941 does not solve the issue of
blacklisting for instance all hosts belonging to a given /64 prefix
(e.g., all users of a hotel, IETF meeting, etc.).
=> and what you want to do if for instance someone blacklists all hosts
belonging to a give /32 prefix?
So if you still want to go forward I strongly suggest to make HOST_ID
hard to reverse (i.e., to get the user should require the NAT logs)
and short life.
Med: We have this text in the current version. Do you think we
should add more?
=> add far more
The volatility of the HOST_ID information is similar to the source IP
address: a distinct HOST_ID may be used by the address sharing
function when the host reboots or gets a new internal IP address. If
the HOST_ID is persistent it may be used to track a host (similar to
persistent IP addresses).
=> it doesn't need to be persistent: it just need to have medium/long life.
So IMHO you should develop the text from the last statement and forget
any reference to the source IP address.
(or give up about the whole idea)
Regards
francis.dup...@fdupont.fr
_______________________________________________
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area
