Re: Feedback on draft-gont-6man-stable-privacy-addresses-01

[Fred Baker <[e-mail]>]

On Apr 14, 2012, at 4:20 PM, Christian Huitema wrote:
> 3) Privacy: the number should vary over time, to make it harder for Internet services to correlate sessions started by the same host.
> 4) Stability: the number should remain stable over time, so administrators can more easily manage which host is using what network service.
> 
> Of course, stability and privacy are contradictory, so there must be a way for arbitraging that. That's the big issue to be dealt with by the specification of privacy addresses, i.e. whatever successor we write for RFC 3484. The arbitration will be resolving about how often host generate addresses, how many addresses they generate, and under what circumstances do they use one or the other. Let's assume for now that we just want to generate addresses once per subnet.

That pp mixes two things:

https://tools.ietf.org/html/rfc3484
3484 Default Address Selection for Internet Protocol version 6 (IPv6).
     R. Draves. February 2003. (Format: TXT=55076 bytes) (Status: PROPOSED
     STANDARD)

https://tools.ietf.org/html/rfc4941
4941 Privacy Extensions for Stateless Address Autoconfiguration in
     IPv6. T. Narten, R. Draves, S. Krishnan. September 2007. (Format:
     TXT=56699 bytes) (Obsoletes RFC3041) (Status: DRAFT STANDARD)

I agree that the arbitrage is largely about the rate of address generation. I should think that's a local matter; two otherwise-identical laptops sitting beside each other on a LAN could be different - one changing its address once a week, and the other changing its address for every TCP session. Apart from the impact of DAD, I don't see much harm in letting them do so.

> In principle, there are two ways to meet the unique per subnet requirement: use a number that is guaranteed to be unique by design; or use a large random number that is unlikely to collide with an existing allocation.

That's for global uniqueness. If all that is required is uniqueness in a subnet, something akin to that makes sense for the first guess, but after that it's all about DAD.

> Fernando's algorithm has several advantages. It uses a hash of a pre-allocated random number,

As I read it, section three item one calls for the use of the EUI-64 in use on the interface, which presumes that the interface is an IEEE 802 LAN. There are other interface types. I'd like to see that widened to a number *such*as* one of the set I specified.