Re: "Recommendation on Temporary IPv6 Interface Identifiers" (revised I-D) (Fwd: New Version Notification for draft-gont-6man-non-stable-iids-01.txt)

[Mark Smith <[e-mail]>]

Hi,

Firstly, I really like this draft.

Suggestions/comments:


o  3.3.  Requirements for Temporary IPv6 Addresses

" Temporary addresses MUST have a limited lifetime, which should be
       different for different addresses."

For clarity, I'd suggest adding:

"This includes when a node has different addresses from within the same prefix."

just to be very clear that there is a requirement of individual
addresses, and that it doesn't change if they happen to be from within
the same prefix. (I assume this is the case?)



"  4.  The resulting interface identifiers MUST NOT embed layer-2
       identifiers (e.g.  MAC addresses)."

perhaps add,

"to prevent correlation between IPv6 IIDs and MAC addresses, when an
outside entity has been able to record both."



"This is
   in contrast with e.g. stable addresses [RFC7217], that do not have
   have a limited lifetime."

I think this is technically not true, the standard IPv6 preferred and
valid lifetimes could cause a stable address to expire, so in those
terms stable addresses, as do all IPv6 addresses, have a "lifetime"
which may be limited (static addresses could be considered an
exception, however it is only convention that when they're configured
they have a infinite preferred and valid lifetime.)

Perhaps this would be more accurate:

"This is in contrast with e.g. stable addresses [RFC7217], who's
values do not change in response to a privacy event or the expiration
of a timer, such as the address's preferred or valid lifetime."



"Having a variable maximum lifetime prevents
   an observer from synchronizing with the temporary address
   regeneration; that is, from being able to expect when address will be
   regenerated, and thus infer that one newly observed addresses is the
   result of regenerating a previously observed one."

This draft seems to be going a bit further in this direction (in a
good way) than RFC4941 does (based on my brief reading of "3.5.
Regeneration of Randomized Interface Identifiers") RFC4941 seems to
have either host or interface universal values
(TEMP_PREFERRED_LIFETIME: 1day, TEMP_VALID_LIFETIME:1 week) for the
maximum lifetimes of temporary addresses. It looks to be focusing on
avoiding synchronised address changes across clients rather than
across addresses within a client.



"That is, a host that de-
   attaches from a network and subsequently re-attaches to a (possibly
   different) network should regenerate all of its temporary addresses."

RFC4941 only very briefly deals with this scenario. I agree with doing
it, however I think there is a risk of a DoS on the link or similar if
an interface starts failing, and disconnects/re-connects rapidly. I
think there should be some prevention against this e.g., multiple
disconnects/connects within 3 seconds indicates the interface is
failing and regeneration of temporary addresses should not take place
if this occurs.


"Besides, a node that generates an IPv6 address by embedding
   a link-layer address in the IPv6 address will, when configuring
   addresses for different prefixes, result in the same IID being used
   for such prefixes, thus allowing the corresponding traffic to be
   correlated."

An example of significance might be correlation between internal ULA
address traffic and external GUA address traffic if the IIDs are
shared and the foreign entity has managed to capture both. ULA would
tend to have greater privacy expectations or semantics because they're
not global addresses and not intended to be exposed to global parties.



"The resulting Interface Identifier SHOULD be compared against the
       reserved IPv6 Interface Identifiers [RFC5453] [IANA-RESERVED-IID]
       and against those Interface Identifiers already employed in an
       address of the same network interface and the same network
       prefix."

Also against addresses on different network interfaces attached to the
same network. Perhaps this IID comparison should really be taking
place across all addresses from within and across prefixes independent
of interfaces?  Actually, I think that is really saying that there is
no IID duplication across any of the addresses used by the host.


 "The algorithm in [RFC7217] can be augmented for the generation of
   temporary addresses.  The benefit of this would be that a node could
   employ a single algorithm for generating stable and temporary
   addresses, by employing appropriate parameters.

   Nodes would employ the following algorithm for generating the
   temporary IID:"

A brief mention of what is changed verses RFC7217 before presenting
the algorithm would be useful. It seems MAC_Address and Time are the
differences?

Regarding using the MAC_Address,

"Employing the MAC address in this expression (in replacement of the
Net_Iface parameter of the expression in RFC7217) means that the
re-generation of a randomized MAC address will result in a different
temporary address."

it isn't clear to me whether randomised MAC addresses is a requirement
or a recommendation when using this algorithm. With it replacing
Net_Iface, it seems to be leaning towards a requirement.


nits:

-  " a
   node may want to use only Temporary address (e.g., a temporary
   address)."

This text seemed a little confusing because it seemed the temporary
address text was being repeated. I realised that the capital T
"Temporary" was a special word, perhaps the parenthesis text is
unnecessary here. e.g.

" a node may want to use only Temporary address ."


- In the terminology section, it might be worth quoting a few of the
repeatedly used terms from RFC7721 for the convenience of the reader.
"Temporary address" would be an example.


- Should "stable address" be capitalised throughout as it too is a
term defined in RFC7721?

- With both "Temporary address" and "temporary address" terms both
being used, it seems like there is some sort of difference between
what these terms mean. It's not really obvious to me what that
difference is. It would seem to me that "Temporary address" (and
"Stable address") should always be being used, as their definitions in
RFC7721 would seem to apply universally.


- "3.3. Requirements for Temporary IPv6 Addresses

   The requirements for temporary IPv6 addresses are as follows:"

-"t","+"T"

"The requirements for Temporary IPv6 addresses are as follows:"


Regards,
Mark.