Skip to main content

Temporary Address Extensions for Stateless Address Autoconfiguration in IPv6
draft-ietf-6man-rfc4941bis-12

Revision differences

Document history

Date Rev. By Action
2024-01-26
12 Gunter Van de Velde Request closed, assignment withdrawn: Carlos Martínez Last Call OPSDIR review
2024-01-26
12 Gunter Van de Velde Closed request for Last Call review by OPSDIR with state 'Overtaken by Events': Cleaning up stale OPSDIR queue
2021-02-25
12 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2021-01-25
12 (System) RFC Editor state changed to AUTH48 from RFC-EDITOR
2021-01-11
12 (System) RFC Editor state changed to RFC-EDITOR from EDIT
2021-01-06
12 Christopher Wood Request for Last Call review by SECDIR Completed: Has Issues. Reviewer: Christopher Wood. Sent review to list.
2020-12-14
12 (System) RFC Editor state changed to EDIT
2020-12-14
12 (System) IESG state changed to RFC Ed Queue from Approved-announcement sent
2020-12-14
12 (System) Announcement was received by RFC Editor
2020-12-14
12 (System) IANA Action state changed to No IANA Actions from In Progress
2020-12-14
12 (System) IANA Action state changed to In Progress
2020-12-14
12 Amy Vezza IESG state changed to Approved-announcement sent from Approved-announcement to be sent
2020-12-14
12 Amy Vezza IESG has approved the document
2020-12-14
12 Amy Vezza Closed "Approve" ballot
2020-12-14
12 Amy Vezza Ballot approval text was generated
2020-12-14
12 Amy Vezza Notification list changed to otroan@employees.org from =?utf-8?q?Ole_Tr=C3=B8an?= <otroan@employees.org>
2020-12-14
12 Amy Vezza Ballot approval text was generated
2020-12-13
12 Erik Kline IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup
2020-11-17
12 Benjamin Kaduk [Ballot comment]
Thank you for addressing my Discuss (and Comment) points!
2020-11-17
12 Benjamin Kaduk [Ballot Position Update] Position for Benjamin Kaduk has been changed to Yes from Discuss
2020-11-02
12 (System) Sub state has been changed to AD Followup from Revised ID Needed
2020-11-02
12 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed
2020-11-02
12 Fernando Gont New version available: draft-ietf-6man-rfc4941bis-12.txt
2020-11-02
12 (System) New version approved
2020-11-02
12 (System) Request for posting confirmation emailed to previous authors: Thomas Narten , Richard Draves , Suresh Krishnan , Fernando Gont
2020-11-02
12 Fernando Gont Uploaded new revision
2020-10-22
11 Cindy Morgan IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation
2020-10-22
11 Robert Wilton [Ballot Position Update] New position, No Objection, has been recorded for Robert Wilton
2020-10-22
11 Magnus Westerlund
[Ballot comment]
I understand that this is an update of an older document resolving several important issues. However, what was advanced traffic analysis 10 years …
[Ballot comment]
I understand that this is an update of an older document resolving several important issues. However, what was advanced traffic analysis 10 years ago is not as advanced today. The security consideration discuss some of the weakness. To me it appears that there are significant risks of correlation old temporary address passed preferred life time with the new preferred temporary address. Especially if an attacker can trigger an endpoint reconnecting to a site where the previous temporary address was used and thus correlate the attempt to force reconnection combined detected use of a new temporary address to the same destination. It might even be another destination but associated with the same remote site.

I have not putt this on discuss level, but my impression is that although beneficial the strength of its protection might be overstated in the various statements.
2020-10-22
11 Magnus Westerlund [Ballot Position Update] New position, No Objection, has been recorded for Magnus Westerlund
2020-10-22
11 Murray Kucherawy
[Ballot comment]
I support Benjamin's DISCUSS.

The shepherd writeup says "The original authors from RFC4941 have not been reachable", but those were S. Krishnan, R. …
[Ballot comment]
I support Benjamin's DISCUSS.

The shepherd writeup says "The original authors from RFC4941 have not been reachable", but those were S. Krishnan, R. Draves, and T. Narten, who are three of the authors of this document.  I'm confused.
2020-10-22
11 Murray Kucherawy [Ballot Position Update] New position, No Objection, has been recorded for Murray Kucherawy
2020-10-21
11 Barry Leiba [Ballot comment]
I support Ben's DISCUSS.
2020-10-21
11 Barry Leiba [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba
2020-10-21
11 Alissa Cooper [Ballot comment]
Glad to see this update.
2020-10-21
11 Alissa Cooper [Ballot Position Update] New position, Yes, has been recorded for Alissa Cooper
2020-10-20
11 Dave Thaler Request for Telechat review by IOTDIR Completed: Ready with Issues. Reviewer: Dave Thaler. Sent review to list.
2020-10-20
11 Deborah Brungard [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard
2020-10-20
11 Roman Danyliw
[Ballot comment]
I support Ben Kaduk’s DISCUSS position around the need for clarity on what “statistically different” means (per Section 3).

I also strongly concur …
[Ballot comment]
I support Ben Kaduk’s DISCUSS position around the need for clarity on what “statistically different” means (per Section 3).

I also strongly concur with Ben’s guidance on the construction of the RID in Section 3.3.1

** Section 3.*.  The guidance uses the language of “deprecate”.  This to me would suggest some notion of state being kept where I know I’ve used an address before and I won’t use it again.  However, that doesn’t seem right here.

** Section 3.1.  Per “it must be difficult for an outside entity …”, what’s the rough thinking on the workload for “difficult” or is there more precise language.  I ask because Section 2.1

** Section 3.3. The subsections present two different algorithms.  Is there an MTI approach?

** Section 3.3.2.  This section suggests that use of SHA-256, but is there normative guidance on an MTI algorithm?

** Section 3.3.2.  If the hash algorithm output length exceeds the needed identifier length, how should truncations be handled?

** Editorial
-- Section 1.2.  Nit.  For consistency, s/on-link/on path/
2020-10-20
11 Roman Danyliw [Ballot Position Update] New position, No Objection, has been recorded for Roman Danyliw
2020-10-20
11 Éric Vyncke
[Ballot comment]
Thank you for the work put into this document. It is an important topic and it had stimulated a lot of hot discussions …
[Ballot comment]
Thank you for the work put into this document. It is an important topic and it had stimulated a lot of hot discussions on the 6MAN list ;-)

I also appreciate the new section 3.7 where an admin can disable the mechanism. Is there a reason why this document does not briefly compare its addresses with RFC 7217 (stable address) ? It could be helpful for the reader.

Please find below a couple of non-blocking COMMENT points and nits.

I hope that this helps to improve the document,

Regards,

-éric

== COMMENTS ==

Should link-local address generation also be considered here ? While the text is clear about 'global', there is no clear indication that this document does not apply to link-local addresses.

-- Section 1 --
First sentence, should "or by static configuration" be added ?

Should a reference to DHCPv6 be added ?

-- Section 1.2 --
Should IPPIX collectors also be mentioned in the first bullet list ?

On path attacker (really close to the node though !) can also do the correlation based on the layer-2 address. Should this be added to the 2nd list ?

-- Section 2.2 --
I find the focus on DNS as 'rendez-vous' a little limiting. Why not mentioning DNS-SD or SIP proxy or ... Perhaps, prefixing the explanation with "When DNS is used" rather than using "machine would need a DNS name" (and BTW, it is also limiting to refer to a 'machine' as per container IPv6 address could be used)

-- Section 3.1 --
Point 5) the 2nd and 3rd sentences are really repeating themselves and not bringing a lot of value. Let's keep only one of the 2 or even none as the last sentence is really clear.

-- Section 3.4 --
Should the text be clear on whether optimistic DAD may be used?

-- Section 3.6 --
Last paragraph "when an interface connects to a new (different) link, a new set of temporary addresses MUST be generated immediately" seems to imply more than 1 temporary address with the use of 'set' and the plural form. Unsure whether it is the right behavior (esp if no RA-PIO are received yet).

-- Section 6 --
If only this was not 'future work' but I agree, this is not up to this document to specify such kernel API/implementation.

-- Section 9 --
Should the ingress filtering be also part of the section 4 (implications) ?

-- Section 11.2 --
I am afraid that RFC 7721 should be normative (introducing a downref though) as it is used in section 1.1 (terminology).
2020-10-20
11 Éric Vyncke [Ballot Position Update] New position, No Objection, has been recorded for Éric Vyncke
2020-10-19
11 Benjamin Kaduk
[Ballot discuss]
(1) I am not entirely sure what we mean by saying that temporary addresses
must have a lifetime that is "statistically different" across …
[Ballot discuss]
(1) I am not entirely sure what we mean by saying that temporary addresses
must have a lifetime that is "statistically different" across different
addresses, and accordingly I am not sure that the procedures in Section
3.4+3.5 for rereshing a temporary address achieve that property.  (The
text about "statistically different" does not appear in RFC 4941, and
the relevant parts of Section 3.4/3.5 are unchanged from RFC 4941, so
this may be the result of an incomplete update.)

Specifically, when Section 3.5 says to "[repeat] the actions described
in Section 3.4, starting at step 4" that seems to (for long-lived PIOs)
result in, e.g., the new temporary address having lifetime
TEMP_VALID_LIFETIME starting at exactly the time when the previous one
expired; wouldn't an observer be able to trivially correlate "new
address showed up with TEMP_VALID_LIFETIME" with "address that expired
at that time"?  Note that the attacker does not need to know the value
of TEMP_VALID_LIFETIME in order to perform a DFT on the distribution of
"new address" events.  (Furthermore, we apparently qualify the
"repeating the actions" with some caveats, which doesn't exactly qualify
as "repeating the actions" anymore.  That said, the caveats currently
listed in Section 3.5 don't seem to be enough to provide the
"statistically different property" in what I believe to be the intended
interpretation.)

(2) Please fix the reference for DupAddrDetectTransmits in Section 3.8
-- it is defined in 4862, while RetransTimer is in 4861.

(3) RFC 4941 cannot be a *normative* reference of this document if we are
going to Obsolete it.
2020-10-19
11 Benjamin Kaduk
[Ballot comment]
Section 1.2

Having followed many of the references from the Introduction, it seems
that there could be an additional aspect to the problem …
[Ballot comment]
Section 1.2

Having followed many of the references from the Introduction, it seems
that there could be an additional aspect to the problem statement,
namely the question of whether an attacker can (statistically) determine
whether or not there is a host at a given address/IID.  When such an
ability is present, techniques (e.g., pen-testing) involving scanning
the entire address space become more feasible.  I do not think this
potential aspect needs to be mentioned, per se, but do not know if it
was considered for inclusion or not.

  The correlation can be performed by

  o  An attacker who is in the path between the node in question and
      the peer(s) to which it is communicating, and who can view the
      IPv6 addresses present in the datagrams.

  o  An attacker who can access the communication logs of the peers
      with which the node has communicated.

(side note) I suppose if some other node in the path kept logs and the
attacker got access to those logs, that would also allow the
correlation, but that's rather an edge case and we don't claim to have
an exhaustive list, so I don't see a need to add complications to this
text.

  Use of temporary addresses will not prevent such payload-based
  correlation, which can only be addressed by widespread deployment of
  encryption as discussed in [RFC7624].  Nor will it prevent an on-link
  observer (e.g. the node's default router) to track all the node's
  addresses.

nit: s/to track/from tracking/

Section 2.1

  Many nodes also have DNS names associated with their addresses, in
  which case the DNS name serves as a similar identifier.  Although the
  DNS name associated with an address is more work to obtain (it may
  require a DNS query), the information is often readily available.  In
  such cases, changing the address on a machine over time would do
  little to address the concerns raised in this document, unless the
  DNS name is changed as well (see Section 4).

nit: perhaps say "at the same time"?

  The use of a constant identifier within an address is of special
  concern because addresses are a fundamental requirement of
  communication and cannot easily be hidden from eavesdroppers and
  other parties.  Even when higher layers encrypt their payloads,

(editorial) the two paragraphs before this one seem to be examples (DNS
names, HTTP cookies) of "identifier[s] that [are] recognizable over time
within different contexts" as discussed in the paragraph prior to them.
This paragraph is getting back to why we care about constant identifiers
in IP addresses; I wonder if some kind of (list?) formatting for the
previous two paragraphs might help indicate the structure of the
discussion.

  Changing global scope addresses over time limits the time window over
  which eavesdroppers and other information collectors may trivially
  correlate network activity when the same address is employed for
  multiple transactions by the same node.  Additionally, it reduces the
  window of exposure of a node via an address that gets revealed as a
  result of active communication.

I'm not 100% sure that I understand what is being exposed by this
"window of exposure" -- is it just "there is a node at this address and
it is responsible for all activities using that address"?  Thus, perhaps
"window of exposure for such correlation"?  (Similar text also appears
in the Abstract.)

  The security and privacy implications of IPv6 addresses are discussed
  in detail in [RFC7721], [RFC7707], and [RFC7217].

A sentence essentially identical to this one already appeared in the
Introduction; I'm not sure if we should de-duplicate.

Section 3.1

  4.  Temporary addresses must have a limited lifetime (limited "valid
      lifetime" and "preferred lifetime" from [RFC4862]), that should
      be statistically different for different addresses.  The lifetime

We should probably be more specific about what "statistically different" is
supposed to mean.  For example, is it intended to relate to the initial
value associated with a freshly generated address (i.e., "should not be
exactly 24 hour lifetime at time of generation") or the offset between
different addresses ("should not be exactly 24 hours more than the
previous one")?

  5.  By default, one address is generated for each prefix advertised
      by stateless address autoconfiguration.  The resulting Interface
      Identifiers must be statistically different when addresses are
      configured for different prefixes.  That is, when temporary

[In contrast, this use of "statistically different" is both (1)
clarified further and (2) for a time-independent quantity, so the
interpretation is pretty clear as-is.]

Section 3.3.1

I think we need to say something about the random number being long
enough or getting more random bits in step 2 if there aren't enough
bits, or similar.  Just "obtain a random number" doesn't say what the
number is sampled from, and could cover, e.g., https://xkcd.com/221/ .

Section 3.3.2

  1.  Compute a random identifier with the expression:

      RID = F(Prefix, Net_Iface, Network_ID, Time, DAD_Counter,
      secret_key)
  [...]
      F():
          A pseudorandom function (PRF) that MUST NOT be computable from
          the outside (without knowledge of the secret key).  F() MUST
          also be difficult to reverse, such that it resists attempts to
          obtain the secret_key, even when given samples of the output
          of F() and knowledge or control of the other input parameters.
          F() SHOULD produce an output of at least 64 bits.  F() could
          be implemented as a cryptographic hash of the concatenation of
          each of the function parameters.  SHA-256 [FIPS-SHS] is one
          possible option for F().  Note: MD5 [RFC1321] is considered
          unacceptable for F() [RFC6151].

I recognize that this is just the RFC 7217 construction with the 'Time'
parameter added, but it's not entirely clear that we want to be
recommending the plain "hash of concatenation" option without additional
caveats.  While having the secret key be the last element in the
bitstring seems to close off the length-extension class of attacks, we
don't say anything about performing the concatenation with fixed-width
types (or a length prefix), as is needed for non-malleability of the
hash inputs.  (This is particularly of note for the IPv6 prefix, that
one might naturally encode as just the prefix parts, not necessarily
fixed length, but also applies to other parameters, including some of
the "Net_Iface" examples given in RFC 7217.)  There is also no
discussion about the potential for hash collisions (or, more generally,
attacks) across this construction and the RFC 7217 construction.
Guidance to not reuse a secret_key for both constructions would be in
order.  (I will note that it may be tempting to upgrade to an HMAC
construction, and while that will certainly work, modulo the need for
length prefixes/fixed-length input, it is overkill for this case.)
Finally, the guidance for "SHOULD produce an output of at least 64 bits"
could perhaps be revisited; any useful cryptographic hash these days is
going to have at least 128 bits of output, which is certainly enough for
generating an IID!

      Prefix:
          The prefix to be used for SLAAC, as learned from an ICMPv6
          Router Advertisement message.

(side note) is the "as learned from an ICMPv6 RA" an important
prerequisite, or could a prefix learned in some other fashion still be
usable?

          which this interface is associated.  Additionally, Simple DNA
          [RFC6059] describes ideas that could be leveraged to generate
          a Network_ID parameter.  This parameter is SHOULD be employed
          if some form of "Network_ID" is available.

nit: s/is SHOULD/SHOULD/

Section 3.4

  7.  The node MUST perform duplicate address detection (DAD) on the
      generated temporary address.  If DAD indicates the address is
      already in use, the node MUST generate a new randomized interface
      identifier, and repeat the previous steps as appropriate up to
      TEMP_IDGEN_RETRIES times.  If after TEMP_IDGEN_RETRIES
      consecutive attempts no non-unique address was generated, the
      node MUST log a system error and SHOULD NOT attempt to generate a
      temporary address for the given prefix for the duration of the
      node's attachment to the network via this interface.  [...]

Just to confirm my understanding: "for the duration of the node's
attachment to the network" means that even if a new RA+PIO is received,
the node still ignores that prefix?

Section 3.6

  determine that the link change has occurred.  One such process is
  described by "Simple Procedures for Detecting Network Attachment in
  IPv6" [RFC6059].  Detecting link changes would prevent link down/up

nit: we have already referred to the abbreviated name "Simple DNA"
earlier in this document, so the expanded title does not seem necessary
here.

Section 3.8

  REGEN_ADVANCE -- 2 + (TEMP_IDGEN_RETRIES * DupAddrDetectTransmits *
  RetransTimer / 1000)

Please indicate the units of this value (the division by 1000 indicates
it is likely measured in seconds).

  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).

Computing only at startup and not changing it could perhaps run into
issues with maintaining the invariant, when TEMP_PREFERRED_LIFETIME and
REGEN_ADVANCE are configurable after startup.  (Changing DESYNC_FACTOR
more often, and having the range be more like half of the overall
lifetime, would be one approach for achieving the "statistically
different" property mentioned in my Discuss point.)

Section 4.

  The desires of protecting individual privacy versus the desire to
  effectively maintain and debug a network can conflict with each
  other.  [...]

(editorial) this sentence lacks parallelism of structure.  Perhaps:

% The desire to protect individual privacy can conflict with the desire
% to effectively maintain and debug a network.

Section 5

  o  Addresses all errata submitted for [RFC4941].

There are errata reports against RFC 4941 that are still in the state
"reported"; the responsible AD should probably process those before this
document gets published.

Section 9

Overall these security considerations seem pretty comprehensive and
well-described -- thank you!

  If a very small number of nodes (say, only one) use a given prefix
  for extended periods of time, just changing the interface identifier
  part of the address may not be sufficient to mitigate address-based
  network activity correlation, since the prefix acts as a constant
  identifier.  [...]

It might be worth noting some scenarios where this commonly occurs,
e.g., residential households that only have a single computer.  (Is it
also the case for mobile phones?)

  fairly large number of nodes.  Additionally, if a temporary address
  is used in a session where the user authenticates, any notion of
  "privacy" for that address is compromised.

Compromised for the part(ies) that receive the authentication information,
at least.  That does not necessarily include a passive observer in the
network.

  While this document discusses ways of obscuring a user's IP address,
  the method described is believed to be ineffective against

I don't think "obscuring" is the right word -- the IP address is still
visible; we're just trying to remove some of the information content
from it over long periods of time.  I understand the desire to remove
the word "permanent" from the RFC 4941 version, but this still doesn't
seem right.  Perhaps the goal could be rephrased as something about
making the IP address less useful as a persistent (numerical) identifier.

  Ingress filtering has been and is being deployed as a means of
  preventing the use of spoofed source addresses in Distributed Denial
  of Service (DDoS) attacks.  In a network with a large number of
  nodes, new temporary addresses are created at a fairly high rate.
  This might make it difficult for ingress filtering mechanisms to
  distinguish between legitimately changing temporary addresses and
  spoofed source addresses, which are "in-prefix" (using a
  topologically correct prefix and non-existent interface ID).  This
  can be addressed by using access control mechanisms on a per-address
  basis on the network egress point.

Should we say something about the corresponding resource consumption
increase at the egress point?

Section 11.1

One might argue that RFC 7217 is merely informative, since we duplicate
in full the IID-generation algorithm from it (with modifications).

RFC 8190 is only referenced to note that we specifically do *not* use
terminology from it; that seems like it does not really meet the
threshold for being a normative reference.
2020-10-19
11 Benjamin Kaduk [Ballot Position Update] New position, Discuss, has been recorded for Benjamin Kaduk
2020-10-19
11 Alvaro Retana
[Ballot comment]
§3.3 (Generation of Randomized Interface Identifiers) starts by saying that the "subsections specify example algorithms".  Are these algorithms just examples?  Digging through the …
[Ballot comment]
§3.3 (Generation of Randomized Interface Identifiers) starts by saying that the "subsections specify example algorithms".  Are these algorithms just examples?  Digging through the archive, it looks like they are: "It's one possible algorithm, and not necessarily the recommended one." [1]

However, §3.4 (Generating Temporary Addresses) says this:

  6.  New temporary addresses MUST be created by appending a randomized
      interface identifier (generated as described in Section 3.3 of
      this document) to the prefix that was received.

IOW, it makes the algorithms in §3.3 mandatory ("MUST...as described in Section 3.3"). 


Please clarify the text one way or the other: by eliminating "examples" from §3.3, or removing the text in parenthesis in §3.4.


[1] https://mailarchive.ietf.org/arch/msg/ipv6/OVdexfOXgdDM4r1QZ3iQcA_oWVQ
2020-10-19
11 Alvaro Retana [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana
2020-10-15
11 (System) IANA Review state changed to IANA OK - No Actions Needed from Version Changed - Review Needed
2020-10-13
11 Samita Chakrabarti Request for Telechat review by IOTDIR is assigned to Dave Thaler
2020-10-13
11 Samita Chakrabarti Request for Telechat review by IOTDIR is assigned to Dave Thaler
2020-10-12
11 Martin Duke [Ballot Position Update] New position, No Objection, has been recorded for Martin Duke
2020-10-11
11 Éric Vyncke Requested Telechat review by IOTDIR
2020-10-11
11 Éric Vyncke Requested Telechat review by INTDIR
2020-10-10
11 Erik Kline Placed on agenda for telechat - 2020-10-22
2020-10-10
11 Erik Kline IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead
2020-10-10
11 Erik Kline IESG state changed to Waiting for AD Go-Ahead from Waiting for Writeup
2020-10-10
11 Erik Kline Ballot has been issued
2020-10-10
11 Erik Kline [Ballot Position Update] New position, Yes, has been recorded for Erik Kline
2020-10-10
11 Erik Kline Created "Approve" ballot
2020-10-10
11 Erik Kline Ballot writeup was changed
2020-09-30
11 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed
2020-09-30
11 Fernando Gont New version available: draft-ietf-6man-rfc4941bis-11.txt
2020-09-30
11 (System) New version approved
2020-09-30
11 (System) Request for posting confirmation emailed to previous authors: Suresh Krishnan , Thomas Narten , Richard Draves , Fernando Gont , 6man-chairs@ietf.org
2020-09-30
11 Fernando Gont Uploaded new revision
2020-09-23
10 (System) IESG state changed to Waiting for Writeup from In Last Call
2020-09-22
10 (System) IANA Review state changed to IANA OK - No Actions Needed from IANA - Review Needed
2020-09-22
10 Sabrina Tanamal
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has reviewed draft-ietf-6man-rfc4941bis-10, which is currently in Last Call, and has the following comments:

The …
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has reviewed draft-ietf-6man-rfc4941bis-10, which is currently in Last Call, and has the following comments:

The IANA Services Operator notes that this document does not contain a standard IANA Considerations section. After examining the draft, we understand that, upon approval of this document, there are no IANA Actions that need completion.

If this assessment is not accurate, please respond as soon as possible.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist
2020-09-22
10 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Carlos Martínez
2020-09-22
10 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Carlos Martínez
2020-09-11
10 Russ Housley Request for Last Call review by GENART Completed: Almost Ready. Reviewer: Russ Housley. Sent review to list.
2020-09-11
10 Jean Mahoney Request for Last Call review by GENART is assigned to Russ Housley
2020-09-11
10 Jean Mahoney Request for Last Call review by GENART is assigned to Russ Housley
2020-09-10
10 Tero Kivinen Request for Last Call review by SECDIR is assigned to Christopher Wood
2020-09-10
10 Tero Kivinen Request for Last Call review by SECDIR is assigned to Christopher Wood
2020-09-09
10 Cindy Morgan IANA Review state changed to IANA - Review Needed
2020-09-09
10 Cindy Morgan
The following Last Call announcement was sent out (ends 2020-09-23):

From: The IESG
To: IETF-Announce
CC: ek.ietf@gmail.com, draft-ietf-6man-rfc4941bis@ietf.org, 6man-chairs@ietf.org, otroan@employees.org, =?utf-8?q?Ole_Tr=C3=B8an?= …
The following Last Call announcement was sent out (ends 2020-09-23):

From: The IESG
To: IETF-Announce
CC: ek.ietf@gmail.com, draft-ietf-6man-rfc4941bis@ietf.org, 6man-chairs@ietf.org, otroan@employees.org, =?utf-8?q?Ole_Tr=C3=B8an?= , ipv6@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Temporary Address Extensions for Stateless Address Autoconfiguration in IPv6) to Proposed Standard


The IESG has received a request from the IPv6 Maintenance WG (6man) to
consider the following document: - 'Temporary Address Extensions for
Stateless Address Autoconfiguration
  in IPv6'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2020-09-23. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This document describes an extension that causes nodes to generate
  global scope addresses with randomized interface identifiers that
  change over time.  Changing global scope addresses over time limits
  the window of time during which eavesdroppers and other information
  collectors may trivially perform address-based network activity
  correlation when the same address is employed for multiple
  transactions by the same node.  Additionally, it reduces the window
  of exposure of a node via an address that becomes revealed as a
  result of active communication.  This document obsoletes RFC4941.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-6man-rfc4941bis/



No IPR declarations have been submitted directly on this I-D.




2020-09-09
10 Cindy Morgan IESG state changed to In Last Call from Last Call Requested
2020-09-09
10 Erik Kline Last call was requested
2020-09-09
10 Erik Kline Last call announcement was generated
2020-09-09
10 Erik Kline Ballot approval text was generated
2020-09-09
10 Erik Kline Ballot writeup was generated
2020-09-09
10 Erik Kline IESG state changed to Last Call Requested from AD Evaluation::AD Followup
2020-08-26
10 (System) Sub state has been changed to AD Followup from Revised ID Needed
2020-08-26
10 Fernando Gont New version available: draft-ietf-6man-rfc4941bis-10.txt
2020-08-26
10 (System) New version approved
2020-08-26
10 (System) Request for posting confirmation emailed to previous authors: 6man-chairs@ietf.org, Thomas Narten , Richard Draves , Fernando Gont , Suresh Krishnan
2020-08-26
10 Fernando Gont Uploaded new revision
2020-08-16
09 Erik Kline
Thank you for this, and my apologies for taking so long to give it the
requisite attention.

[[ comments ]]

[ abstract ]

* "via …
Thank you for this, and my apologies for taking so long to give it the
requisite attention.

[[ comments ]]

[ abstract ]

* "via an addresses that becomes" -> "via any addresses that become", or
  "via an address that becomes"

[ section 1.2 ]

* I'm not sure that RFC 7624 "advocates" encryption, or at least I can't
  find any solid "should", "must", or "recommend{,s,ation}" etc in there.

  Perhaps s/advocated in/discussed in/.

[ section 3.3.1 ]

* (2) Perhaps "reduced entropy (...)." -> "reduced entropy (...) and increased
  likelihood of collision.", just to be a bit more clear about the risks.

* (3) Under what circumstances would it be okay for an implementation to
  violate this SHOULD?  I guess I'm wondering why it's not a MUST.

* Should we also say that the generated address MAY be compared to addresses
  in the neighbor table, perhaps restricted to neighbors in certain states
  (e.g. reachable, stale, probe)?

[ section 3.3.2 ]

* Similar questions to the above?

* Given that the steps to evaluate a candidate temporary address should almost
  certainly be identical regardless of the generation technique, consider
  a separate section referenced from each of 3.3.1 and 3.3.2.

[ section 3.4 ]

* (6) "generates as" -> "generated as"

* (7) I think this MUST NOT is a bit over-prescriptive as currently written.

  I'd propose replacing "MUST NOT.*" with something like "SHOULD NOT attempt
  to generate a temporary address for the given prefix for the duration of
  the node's attachment to the network via this interface."

  There are 3 proposed changes in there:

    - MUST NOT -> SHOULD NOT

    - specify disabling per prefix (I see no good reason to disable temp addrs
      in other prefixes if they're passing DAD)

    - specify disabling for the lifetime the attachment to the network via
      that interface (or some other text that maybe includes interface up/down
      events etc.).

[ section 3.7 ]

* As I read it, the last paragraph has a MUST for the same text where the first
  paragraph has a SHOULD.  Suggest deleting the last (3rd) paragraph? It seems
  largely redundant to the text in the 1st and 2nd paragraphs.

[ section 3.8 ]

* Might want to add that TEMP_PREFERRED_LIFETIME value MUST be less than
  the TEMP_VALID_LIFETIME value.
2020-08-16
09 Erik Kline IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation
2020-06-24
09 Erik Kline IESG state changed to AD Evaluation from Publication Requested
2020-06-04
09 Ole Trøan
As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.


This version is dated …
As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.


This version is dated 1 November 2019.


(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?


Proposed standard. Type is indicated on the title page.
A host's selection of an interface identifier can be thought of as an internal only matter. The number of addresses and frequency of change has implications on the network and other infrastructure, requiring prescribed behaviour, which is why it is a standards track document.


(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:


Technical Summary:


Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction.


  This document describes an extension that causes nodes to generate
  global scope addresses with randomized interface identifiers that
  change over time.  Changing global scope addresses over time limits
  the window of time during which eavesdroppers and other information
  collectors may trivially perform address-based network activity
  correlation when the same address is employed for multiple
  transactions by the same node.  Additionally, it reduces the window
  of exposure of a node via an addresses that becomes revealed as a
  result of active communication.  This document obsoletes RFC4941.


Working Group Summary:


Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough?


No.


Document Quality:


Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, YANG Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted?


There are multiple implementations of the mechanism described.


Personnel:


Who is the Document Shepherd? Who is the Responsible Area Director?


Ole Trøan is the document shepherd and Erik Kline is the responsible AD.


(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.


This document is an update of RFC4941. The document shepherd has reviewed every change to the document as it has processed as well as a thorough read through of the whole final document.


(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?


No


(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.


The recommendation in RFC4941 was created when the default IPv6 IIDs in SLAAC were based on EUI-64 identifiers. That is, containing a globally unique identifier that could be used to track user's across networks.
The mechanism's purpose is to improve a user's privacy and the document shepherd has asked for reviews specifically in that area (review by Christian Huitema).
The mechanism also has operational consequences for the network. Where hosts have many addresses that change relatively frequently. The operational considerations have been discussed and reviewed on the mailing list.


(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.


There are no concerns.


(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?


Fernando Gont and Suresh Krishnan have confirmed conformance.
The original authors from RFC4941 have not been reachable.


(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.


No.


(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?


This is a document the working group has worked on through 3 iterations. There is strong consensus behind the document.


(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)


No.


(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.


There are no nits.


(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.


None required.


(13) Have all references within this document been identified as either normative or informative?


Yes.


(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?


No.


(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.


There are no downward references.


(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.


This document obsoletes RFC4941. That is listed on the title page.


(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).


No IANA considerations.


(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.


None.


(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.


There are none.


(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?


This document does not contain a YANG module.
2020-06-04
09 Ole Trøan Responsible AD changed to Erik Kline
2020-06-04
09 Ole Trøan IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up
2020-06-04
09 Ole Trøan IESG state changed to Publication Requested from I-D Exists
2020-06-04
09 Ole Trøan IESG process started in state Publication Requested
2020-06-04
09 Ole Trøan Changed consensus to Yes from Unknown
2020-06-04
09 Ole Trøan Intended Status changed to Proposed Standard from None
2020-06-04
09 Ole Trøan
As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.


This version is dated …
As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.


This version is dated 1 November 2019.


(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?


Proposed standard. Type is indicated on the title page.
A host's selection of an interface identifier can be thought of as an internal only matter. The number of addresses and frequency of change has implications on the network and other infrastructure, requiring prescribed behaviour, which is why it is a standards track document.


(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:


Technical Summary:


Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction.


  This document describes an extension that causes nodes to generate
  global scope addresses with randomized interface identifiers that
  change over time.  Changing global scope addresses over time limits
  the window of time during which eavesdroppers and other information
  collectors may trivially perform address-based network activity
  correlation when the same address is employed for multiple
  transactions by the same node.  Additionally, it reduces the window
  of exposure of a node via an addresses that becomes revealed as a
  result of active communication.  This document obsoletes RFC4941.


Working Group Summary:


Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough?


No.


Document Quality:


Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, YANG Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted?


There are multiple implementations of the mechanism described.


Personnel:


Who is the Document Shepherd? Who is the Responsible Area Director?


Ole Trøan is the document shepherd and Erik Kline is the responsible AD.


(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.


This document is an update of RFC4941. The document shepherd has reviewed every change to the document as it has processed as well as a thorough read through of the whole final document.


(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?


No


(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.


The recommendation in RFC4941 was created when the default IPv6 IIDs in SLAAC were based on EUI-64 identifiers. That is, containing a globally unique identifier that could be used to track user's across networks.
The mechanism's purpose is to improve a user's privacy and the document shepherd has asked for reviews specifically in that area (review by Christian Huitema).
The mechanism also has operational consequences for the network. Where hosts have many addresses that change relatively frequently. The operational considerations have been discussed and reviewed on the mailing list.


(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.


There are no concerns.


(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?


Fernando Gont and Suresh Krishnan have confirmed conformance.
The original authors from RFC4941 have not been reachable.


(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.


No.


(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?


This is a document the working group has worked on through 3 iterations. There is strong consensus behind the document.


(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)


No.


(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.


There are no nits.


(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.


None required.


(13) Have all references within this document been identified as either normative or informative?


Yes.


(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?


No.


(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.


There are no downward references.


(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.


This document obsoletes RFC4941. That is listed on the title page.


(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).


No IANA considerations.


(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.


None.


(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.


There are none.


(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?


This document does not contain a YANG module.
2020-06-03
09 Ole Trøan Notification list changed to =?utf-8?q?Ole_Tr=C3=B8an?= <otroan@employees.org>
2020-06-03
09 Ole Trøan Document shepherd changed to Ole Trøan
2020-06-02
09 Ole Trøan IETF WG state changed to WG Consensus: Waiting for Write-Up from In WG Last Call
2020-04-06
09 Fernando Gont New version available: draft-ietf-6man-rfc4941bis-09.txt
2020-04-06
09 (System) New version approved
2020-04-06
09 (System) Request for posting confirmation emailed to previous authors: Fernando Gont , Thomas Narten , Richard Draves , Suresh Krishnan
2020-04-06
09 Fernando Gont Uploaded new revision
2020-03-27
08 Fernando Gont New version available: draft-ietf-6man-rfc4941bis-08.txt
2020-03-27
08 (System) New version approved
2020-03-27
08 (System) Request for posting confirmation emailed to previous authors: Richard Draves , Thomas Narten , Suresh Krishnan , Fernando Gont
2020-03-27
08 Fernando Gont Uploaded new revision
2020-02-26
07 Fernando Gont New version available: draft-ietf-6man-rfc4941bis-07.txt
2020-02-26
07 (System) New version approved
2020-02-26
07 (System) Request for posting confirmation emailed to previous authors: Thomas Narten , Fernando Gont , Suresh Krishnan , Richard Draves
2020-02-26
07 Fernando Gont Uploaded new revision
2020-02-09
06 Fernando Gont New version available: draft-ietf-6man-rfc4941bis-06.txt
2020-02-09
06 (System) New version approved
2020-02-09
06 (System) Request for posting confirmation emailed to previous authors: Fernando Gont , Suresh Krishnan , Richard Draves , Thomas Narten
2020-02-09
06 Fernando Gont Uploaded new revision
2020-01-09
05 Bob Hinden IETF WG state changed to In WG Last Call from WG Document
2019-12-10
05 Fernando Gont New version available: draft-ietf-6man-rfc4941bis-05.txt
2019-12-10
05 (System) New version approved
2019-12-10
05 (System) Request for posting confirmation emailed to previous authors: Fernando Gont , Suresh Krishnan , Richard Draves , Thomas Narten
2019-12-10
05 Fernando Gont Uploaded new revision
2019-11-03
04 Fernando Gont New version available: draft-ietf-6man-rfc4941bis-04.txt
2019-11-03
04 (System) New version approved
2019-11-03
04 (System) Request for posting confirmation emailed to previous authors: Fernando Gont , Suresh Krishnan , Richard Draves , Thomas Narten
2019-11-03
04 Fernando Gont Uploaded new revision
2019-09-05
03 Fernando Gont New version available: draft-ietf-6man-rfc4941bis-03.txt
2019-09-05
03 (System) New version approved
2019-09-05
03 (System) Request for posting confirmation emailed to previous authors: Fernando Gont , Suresh Krishnan , Richard Draves , Thomas Narten
2019-09-05
03 Fernando Gont Uploaded new revision
2019-07-08
02 Fernando Gont New version available: draft-ietf-6man-rfc4941bis-02.txt
2019-07-08
02 (System) New version approved
2019-07-08
02 (System) Request for posting confirmation emailed to previous authors: Fernando Gont , Suresh Krishnan , Richard Draves , Thomas Narten
2019-07-08
02 Fernando Gont Uploaded new revision
2019-03-11
01 Fernando Gont New version available: draft-ietf-6man-rfc4941bis-01.txt
2019-03-11
01 (System) New version approved
2019-03-11
01 (System) Request for posting confirmation emailed to previous authors: Fernando Gont , Suresh Krishnan , Richard Draves , Thomas Narten
2019-03-11
01 Fernando Gont Uploaded new revision
2019-01-03
00 (System) Document has expired
2018-07-02
00 Bob Hinden This document now replaces draft-fgont-6man-rfc4941bis instead of None
2018-07-02
00 Fernando Gont New version available: draft-ietf-6man-rfc4941bis-00.txt
2018-07-02
00 (System) WG -00 approved
2018-07-02
00 Fernando Gont Set submitter to "Fernando Gont ", replaces to draft-fgont-6man-rfc4941bis and sent approval email to group chairs: 6man-chairs@ietf.org
2018-07-02
00 Fernando Gont Uploaded new revision