ietf
[Top] [All Lists]

RE: last call comments for draft-ietf-6man-stable-privacy-addresses-06

2013-04-23 12:03:22
After reading the document again, the main issue is that the document specifies 
a solution to a problem by detailing a specific implementation, but does not 
explain the design choices behind that solution. As such, we end up with an 
over constrained specification, which at the same time fails to explain the 
problems at hand. The specification aims at providing addresses that are 
"stable and different," so that the same host connecting will have different 
and uncorrelated addresses when connecting to different networks, but will keep 
the same address when connecting repeatedly to the same network. 

As Mike St-Johns pointed out, the solution is trivial: create a different 
random number each time the host connect to a new network; make sure that the 
same random number is reused if the host reconnect to the same network. The 
latter property can be achieved either by keeping of log of previously visited 
networks and the corresponding address, or by using a "master random number" 
and combining it with the identification of the visited network. In theory, 
that's about all what the IETF ought to specify.

Instead, the draft goes into great details on how to actually implement the 
random number generator. Apart from not being necessary, some of these details 
are wrong. For example, the suggested algorithm includes an "interface index," 
but different operating systems have different ways of enumerating interfaces, 
and the variations in enumeration could end up violating the "stable address" 
property. 

I would suggest reworking the draft to separate a normative section, 
effectively a variation of the 3 lines paragraph above, and an informational 
section, the current specification of the algorithm as  "an example of a way to 
achieve this result if the operating system meets certain condition, like 
stable interface identifiers."

I would also explain the inherent issues that have to be solved, e.g., swapping 
interfaces, or enabling multi-homed hosts. And I would observe that the DAD 
problem cannot be solved ina  reliable way.

-- Christian Huitema



<Prev in Thread] Current Thread [Next in Thread>