Issues Raised in Chair Review of <draft-ietf-6man-rfc4941bis-05 >

[Bob Hinden <[e-mail]>]

Ole and I did a chairs review of <draft-ietf-6man-rfc4941bis-05>.   Our comments are below.

We sent editorial issues to the authors separately.

Bob & Ole




> 1.  Introduction

This section needs needs to repeat that this obsoletes RFC4941, and good to have a short summary of what changed.

> 2.1.  Extended Use of the Same Identifier


This section is missing a description about tracking stable IIDs when the node connects to different networks.


> 2.2.  Possible Approaches

Better to have this a new section, it’s not part of “Background”.

> 
>   One way to avoid having a stable non-changing address is to use
>   DHCPv6 [RFC8415] for obtaining addresses.  Section 12 of [RFC8415]
>   discusses the use of DHCPv6 for the assignment and management of
>   "temporary addresses", which are never renewed and provide the same
>   property of temporary addresses described in this document with
>   regards to the privacy concern.

We don’t think this should be the first paragraph.   Start with the next paragraph.  Then the DHCPv6 paragraph can be at the end of this section, starting with “Another way…”.

> 
>   One  approach, compatible with the stateless address
>   autoconfiguration architecture, would be to change the interface
>   identifier portion of an address over time.  Changing the interface
>   identifier can make it more difficult to look at the IP addresses in
>   independent transactions and identify which ones actually correspond
>   to the same node, both in the case where the routing prefix portion
>   of an address changes and when it does not.
> 
>   Many machines function as both clients and servers.  In such cases,
>   the machine would need a DNS name for its use as a server.  Whether
>   the address stays fixed or changes has little privacy implication
>   since the DNS name remains constant and serves as a constant
>   identifier.  When acting as a client (e.g., initiating
>   communication), however, such a machine may want to vary the
>   addresses it uses.  In such environments, one may need multiple
>   addresses: a stable address registered in the DNS, that is used to
>   accept incoming connection requests from other machines, and a
>   temporary address used to shield the identity of the client when it
>   initiates communication.
> 
>   On the other hand, a machine that functions only as a client may want
>   to employ only temporary addresses for public communication.
> 
>   To make it difficult to make educated guesses as to whether two
>   different interface identifiers belong to the same node, the
>   algorithm for generating alternate identifiers must include input
>   that has an unpredictable component from the perspective of the
>   outside entities that are collecting information.



3.1.  Assumptions


>   ….
>           This document also
>   assumes that an API will exist that allows individual applications to
>   indicate whether they prefer to use temporary or stable addresses and
>   override the system defaults.

Is this the best approach?   Or should the user be able to configure this on a per node basis?

> 3.2.  Generation of Randomized Interface Identifiers
> 
>   The following subsections specify   example algorithms for
>   generating temporary interface identifiers that follow the guidelines
>   in Section 3 of this document.

s/Section 3/Section 3.1/

> 3.2.1.  Simple Randomized Interface Identifiers
> 
>   One approach is  to select a pseudorandom number of the
>   appropriate length.  A node employing this algorithm should generate
>   IIDs as follows:
> 
>   1.  Obtain a random number (see [RFC4086] for randomness requirements
>       for security).
> 
>   2.  The Interface Identifier is obtained by taking as many bits from
>       the random number obtained in the previous step
>       as necessary.  Note: there are no special bits in an Interface
>       Identifier [RFC7136].
> 
>          We note that [RFC4291] requires that the Interface IDs of all
>          unicast addresses (except those that start with the binary
>          value 000) be 64 bits long.  However, the method discussed in
>          this document could be employed for generating Interface IDs
>          of any arbitrary length, albeit at the expense of reduced
>          entropy (when employing Interface IDs smaller than 64 bits).

It get’s a lot worse if the IID is much smaller, for example, an 8 bit IID is not very useful.   Suggest removing this paragraph or expand it.   The current text doesn’t add very much value.

> 3.2.2.  Hash-based Generation of Randomized Interface Identifiers
> 
>   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:
> 

What are the differences from the RFC7217 algorithm and why is it changed?  It appears to be different.  This makes the statement in the first paragraph incorrect.

> 3.3.  Generating Temporary Addresses
> 
> …..
> 
>   1.  Process the Prefix Information Option as defined in [RFC4862],
>       adjusting the lifetimes of existing temporary addresses.  If a
>       received option may extend the lifetimes of temporary addresses,
>       with the overall constraint that no temporary addresses should
>       ever remain "valid" or "preferred" for a time longer than
>       (TEMP_VALID_LIFETIME) or (TEMP_PREFERRED_LIFETIME -
>       DESYNC_FACTOR) respectively.  The configuration variables
>       TEMP_VALID_LIFETIME and TEMP_PREFERRED_LIFETIME correspond to
>       approximate target lifetimes for temporary addresses.
> 

Why would not each address have an expiration time instead, then DESYNC_FACTOR factor doesn't need to be factored in here?

> 5.  A temporary address is created only if this calculated Preferred
>       Lifetime is greater than REGEN_ADVANCE time units.  In
>       particular, an implementation MUST NOT create a temporary address
>       with a zero Preferred Lifetime.

REGEN_ADVANCE   Please define or explain this variable before use.

> 
> 7.  The node MUST perform duplicate address detection (DAD) on the
> 
…..

> If after TEMP_IDGEN_RETRIES
>       consecutive attempts no non-unique address was generated, the
>       node MUST log a system error and MUST NOT attempt to generate
>       temporary addresses for that interface.

Is that the correct behavior, if so explain why?


> 3.5.  Regeneration of Temporary Addresses
….
> Implementations SHOULD provide end users with the
>   ability to override both of these default values.

Seems doubtful that most users would understand what to do with this.

> 3.6.  Implementation  Considerations
> 
> ….

>   other global prefixes.  Another site might wish to enable temporary
>   address generation only for the prefixes 2001::/16 and 2002::/16

Poor choice of example prefixes.  Use documentation prefixes?


>   while disabling it for all other prefixes.  To support this behavior,
>   implementations SHOULD provide a way to enable and disable generation
>   of temporary addresses for specific prefix subranges.  This per-
>   prefix setting SHOULD override the global settings on the node with
>   respect to the specified prefix subranges.  Note that the per-prefix
>   setting can be applied at any granularity, and not necessarily on a
>   per subnet basis.
> 
>   The use of temporary addresses may cause unexpected difficulties with
>   some applications.  As described below, some servers refuse to accept
>   communications from clients for which they cannot map the IP address
>   into a DNS name.  In addition, some applications may not behave
>   robustly if temporary addresses are used and an address expires
>   before the application has terminated, or if it opens multiple
>   sessions, but expects them to all use the same addresses.

This is not an implementation consideration.   It is also redundant with next section.

> 4.  Implications of Changing Interface Identifiers
> ...
> 
>   Some servers refuse to grant access to clients for which no DNS name
>   exists.  That is, they perform a DNS PTR query to determine the DNS
>   name, and may then also perform an AAAA query on the returned name to
>   verify that the returned DNS name maps back into the address being
>   used.  Consequently, clients not properly registered in the DNS may
>   be unable to access some services.  As noted earlier, however, a
>   node's DNS name (if non-changing) serves as a constant identifier.
>   The wide deployment of the extension described in this document could
>   challenge the practice of inverse-DNS-based "authentication," which
>   has little validity, though it is widely implemented.  In order to
>   meet server challenges, nodes could register temporary addresses in
>   the DNS using random names (for example, a string version of the
>   random address itself).

Is this even used for IPv6?    Relevance for this document?

> 5.  Defined Constants

This needs to be move earlier in the document, before they are used.

> 
>   Constants defined in this document include:
> 
>   TEMP_VALID_LIFETIME -- Default value: 1 week.  Users should be able
>   to override the default value.
> 
>   TEMP_PREFERRED_LIFETIME -- Default value: 1 day.  Users should be
>   able to override the default value.
> 
>   REGEN_ADVANCE -- 5 seconds
> 
>   MAX_DESYNC_FACTOR -- 10 minutes.  Upper bound on DESYNC_FACTOR.
> 
>   DESYNC_FACTOR -- A random value within the range 0 -
>   MAX_DESYNC_FACTOR.  It is computed once at system start (rather than
>   each time it is used) and must never be greater than
>   (TEMP_PREFERRED_LIFETIME - REGEN_ADVANCE).

We don't think the purpose of DESYNC_FACTOR has ever been described?

> 6.  Future Work
> 
>   An implementation might want to keep track of which addresses are
>   being used by upper layers so as to be able to remove a deprecated
>   temporary address from internal data structures once no upper layer
>   protocols are using it (but not before).  This is in contrast to
>   current approaches where addresses are removed from an interface when
>   they become invalid [RFC4862], independent of whether or not upper
>   layer protocols are still using them.  For TCP connections, such
>   information is available in control blocks.  For UDP-based
>   applications, it may be the case that only the applications have
>   knowledge about what addresses are actually in use.  Consequently, an
>   implementation generally will need to use heuristics in deciding when
>   an address is no longer in use.
> 
>   Recommendations on DNS practices to avoid the problem described in
>   Section 4 when reverse DNS lookups fail may be needed.  [RFC4472]
>   contains a more detailed discussion of the DNS-related issues.
> 
>   While this document discusses ways of obscuring a user's IP address,
>   the method described is believed to be ineffective against
>   sophisticated forms of traffic analysis.  To increase effectiveness,
>   one may need to consider the use of more advanced techniques, such as
>   Onion Routing [ONION].

Is this section needed?   Suggest removing it.

> 
> 
> 
> 
> 
> 
> 
> 
> 



>