Subject: [6man] #4: Normative section / Informational section

From: "6man issue tracker" <[email-masked]>
Date: Wed, 08 May 2013 20:14:04 -0000

#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-masked]     |      Owner:  draft-ietf-6man-stable-
     Type:  defect                   |  [email-masked]
 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/>

---

From: "6man issue tracker" <[email-masked]>
Date: Sun, 19 May 2013 17:12:26 -0000

Changes (by [email-masked]):

 * status:  new => closed
 * resolution:   => fixed

Comment:

 My response to this post is available at: <http://www.ietf.org/mail-
 archive/web/ietf/current/msg78813.html>

 That said, as noted in another ticket, the current version of the I-D
 (-07) does not require any specific source for the "interface index" or
 the like, but rather specifies a Net_Iface parameter, and discussed
 desired properties for such parameter, and possible sources for it (along
 with a discussion of the pros and cons).

-- 
-------------------------------------+-------------------------------------
 Reporter:  [email-masked]     |       Owner:  draft-ietf-6man-
     Type:  defect                   |  stable-privacy-
 Priority:  major                    |  [email-masked]
Component:  stable-privacy-          |      Status:  closed
  addresses                          |   Milestone:
 Severity:  Active WG Document       |     Version:
 Keywords:                           |  Resolution:  fixed
-------------------------------------+-------------------------------------

Ticket URL: <http://tools.ietf.org/wg/6man/trac/ticket/4#comment:1>
6man <http://tools.ietf.org/wg/6man/>