Re: Feedback on draft-gont-6man-stable-privacy-addresses-01 (was: Re: Consensus call on adopting:....)

[Karl Auer <[e-mail]>]

On Fri, 2012-04-13 at 15:29 +0200, Fernando Gont wrote:
> "IPv6 implementations conforming to this specification MUST generate
> interface identifiers using the algorithm specified in this section in
> replacement of Modified EUI-64 format identifiers."
> ?

While that is good, it would be clearer if it was expanded out to make
the desired points separately:

   It is intended that the use of Modified-IEEE interface identifiers
   be replaced wherever possible by the use of interface identifiers
   generated as described in this specification.

   When generating interface identifiers, IPv6 implementations
   conforming to this specification MUST use the algorithm specified
   in this section.

   [I'm not sure this is necessary - it seems to be saying that
   "conforming implementations have to conform"]

   IPv6 implementations conforming to this specification MUST NOT use
   Modified-IEEE format interface identifiers [see 4291 Appendix A] for
   any purpose EXCEPT THAT link local addresses MAY be generated using
   Modified-IEEE format interface identifiers.

   [remove everything from EXCEPT THAT onwards if that isn't what you
   intended]

   If for any reason the generation of an interface identifier
   according to this specification fails, IPv6 implementations
   conforming to this specification MUST NOT fall back to
   using Modified-IEEE format interface identifiers.

   Interface identifiers other than Modified-IEEE interface identifiers
   MAY be used in addition to interface identifiers generated according
   to this specification.

> It shouldn't be possible. The idea is that the secret key is set to a
> random number (by default).

I still think you need a special value for "invalid secret key", so that
any systems do not have any way to obtain random numbers can refuse to
autoconfigure if the key is not set.

> > 5: Duplicate address detection is not mentioned explicitly, but probably
> > should be - what happens if a host does DAD and determines that its
> > stable address is already in use?
> 
> Address configuration fails.

That should be in the spec.

> That said, if deemed appropriate, one could include one additional byte,
> "DAD" in the hash function, which is initialized to 0, and that is
> incremented by 1 if the host wants to try a different address if/when
> DAD fails.
> 
> If we do that, the implementations should probably cache the resulting
> address, such that it is stable. (otherwise the resulting address might
> change if the same node was brought up while the node with the
> conflicting address is off).

This may not be possible on systems with no onboard storage, and makes
things much more complicated. I suggest that if DAD fails, then
autoconfiguration should just fail (at least as regards stable
addresses).

> Actually, this algorithm could still be used with longer prefixes (i.e.,
> fewer bits for the IID). So I'm not sure whether we should include this
> requirement. e.g., if we were to eventually allow non-/64 autoconfigured
> addresses, this algorithm could be use without any changes (while the
> traditional MAC-based identifiers couldn't).

I like the 64-bit limitation. Either way it should be made explicit.

> > 7: Add "An implementation SHOULD provide the means for the user to
> > enable and disable the use of stable addresses."
> 
> May be s/stable addresses/this specification/?

Fine.

> (Note that this is a different issue from item #1 above: Item #1 above
> is about what you should do if you implement this spec, while the point
> that I'm making in the previous paragraph is that you SHOULD implement
> this spec).

I don't think a spec can mandate it's own use unless it obsoletes or
updates a spec that mandates something. Your spec would have to update
4291, for example, replacing the whole modified-IEEE thing with your
mechanism. That's a BIG step.

> Additionally, I'd argue that in order to have such thing, then
> 1) You'd need to manually configure your address each time you move from
> one network to another (as with manual configuration requires you to set
> the whole address, rather than just the IID bits), or,

No - you could just have a flag that says "the key is the interface
identifier I want to use - verbatim". Then that IID gets appended to
whatever prefix happens along. Obviously this does NOT have the same
anti-tracking qualities etc, but I can see it being useful. It's
basically a variation on static addresses that allows portability
between networks without having to reconfigure the host. Just as with
other forms of static addressing, it is absolutely the administrator's
problem to avoid conflicts.

Regards, K.

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Karl Auer ([e-mail])
http://www.biplane.com.au/kauer

GPG fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017
Old fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687