#4: Normative section / Informational section 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. -- -------------------------------------+------------------------------------- Reporter: [email protected] | Owner: draft-ietf-6man-stable- Type: defect | [email protected] Priority: major | Status: new Component: stable-privacy- | Milestone: addresses | Version: Severity: Active WG Document | Keywords: -------------------------------------+------------------------------------- Ticket URL: <http://trac.tools.ietf.org/wg/6man/trac/ticket/4> 6man <http://tools.ietf.org/wg/6man/> -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
