Benoit Claise's No Objection on draft-ietf-6man-stable-privacy-addresses-16: (with COMMENT)

["Benoit Claise" <[e-mail]>]

Benoit Claise has entered the following ballot position for
draft-ietf-6man-stable-privacy-addresses-16: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-6man-stable-privacy-addresses/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Please Tim's OPS DIR review (currently under discussion)

First, I would note that I have already contributed comments/text to this
draft, as acknowledged by Fernando.  It’s been a few versions since I
last read it.

The goal of the draft has considerable merit, and I believe the document
is worthy of publication, subject to comments belwo being considered.

I would classify the document as ‘Ready with issues’.

Issues:

1. In the discussion in section 5 on the algorithm, it may be desirable
to suggest that implementations allow a choice of IID generation based on
‘classic’ SLAAC with EUI-64 or via this new proposed method, with a
default of the new method.

2. In the algorithm section, there is a comment that interface names MUST
remain the same across boots or down/up events for the stable privacy
address to remain stable. I have (admittedly some time ago, and in rare
cases) seen Linux installations where network interface names can ‘swap’,
thus changing the address in use on the interface under the proposed
algorithm, whereas with existing EUI64 SLAAC the IIDs would remain the
same even if the interface name for a physical interface changed. This is
probably rather more likely if replacing a network card on motherboard
with on-board NIC(s).  Perhaps Fernando can comment on whether this is a
realistic concern with modern OSes.

3. I assume the IID may/will vary for a different OS run on the same
host, e.g. where the host is dual-boot, or where a new OS installed (or
the same OS re-installed). A different OS may well use a different F(),
given that’s not specified.  With EUI-64, a dual-boot host would likely
have the same address under either OS (well, not Windows any more…). 
This may be worth making explicit.

4. The draft talks (in one place in Section 3) about stable privacy
addresses being allocated by DHCPv6; some further discussion of how this
might be achieved may be useful given the secret key is presumed to be
generated on and reside on the host, not the DHCPv6 server.  Or would
this be described in a separate future draft?  This may be a case where
the administrator being able to display or change the secret key needs to
be more than a MAY as currently satted in the text.

5. Design goal 1 might add “and same interface” for scenarios where a
host has two interfaces in the same subnet (with the same prefix).  This
scenario is one that may cause ‘interesting’ effects with addresses if
interface names swap and no Network_ID is used.

6. I’d suggest not mentioning MD5.

Nits:

1. Some references are included multiple times, e.g. [RFC4941], rather
than only at the first instance.

2. Design goal 2, perhaps say “must” rather than “do”?

3. In section 4 the author states the goal of stable IIDs within a given
subnet. It may be better to say for a given prefix, given a renumbering
process will change the prefix and with it the IID, though by loose
language you might refer to it as the same subnet.

In response to recent discussion on 6man, I don’t believe it’s practical
or desirable for a node to store addresses related to locations
(networks) visited.  I agree with the author that the static address per
network should be generated statelessly.