Temporary Address Extensions for Stateless Address Autoconfiguration in IPv6
RFC 8981
Revision differences
Document history
| Date | Rev. | By | Action |
|---|---|---|---|
|
2021-04-30
|
12 | Bernie Volz | Closed request for Telechat review by INTDIR with state 'Overtaken by Events' |
|
2021-02-28
|
12 | (System) | Received changes through RFC Editor sync (created alias RFC 8981, changed abstract to 'This document describes an extension to IPv6 Stateless Address Autoconfiguration that … Received changes through RFC Editor sync (created alias RFC 8981, changed abstract to 'This document describes an extension to IPv6 Stateless Address Autoconfiguration that causes hosts to generate temporary addresses with randomized interface identifiers for each prefix advertised with autoconfiguration enabled. Changing 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 host. Additionally, it reduces the window of exposure of a host as being accessible via an address that becomes revealed as a result of active communication. This document obsoletes RFC 4941.', changed pages to 20, changed standardization level to Proposed Standard, changed state to RFC, added RFC published event at 2021-02-28, changed IESG state to RFC Published, created obsoletes relation between draft-ietf-6man-rfc4941bis and RFC 4941) |
|
2021-02-28
|
12 | (System) | RFC published |
|
2021-02-25
|
12 | (System) | RFC Editor state changed to <a href="http://www.rfc-editor.org/auth48/rfc8981">AUTH48-DONE</a> from AUTH48 |
|
2021-01-25
|
12 | (System) | RFC Editor state changed to <a href="http://www.rfc-editor.org/auth48/rfc8981">AUTH48</a> 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 <narten@cs.duke.edu>, Richard Draves <richdr@microsoft.com>, Suresh Krishnan <suresh@kaloom.com>, Fernando Gont … Request for posting confirmation emailed to previous authors: Thomas Narten <narten@cs.duke.edu>, Richard Draves <richdr@microsoft.com>, Suresh Krishnan <suresh@kaloom.com>, Fernando Gont <fgont@si6networks.com> |
|
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 <suresh@kaloom.com>, Thomas Narten <narten@us.ibm.com>, Richard Draves <richdr@microsoft.com>, Fernando Gont … Request for posting confirmation emailed to previous authors: Suresh Krishnan <suresh@kaloom.com>, Thomas Narten <narten@us.ibm.com>, Richard Draves <richdr@microsoft.com>, Fernando Gont <fgont@si6networks.com>, 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):<br><br>From: The IESG <iesg-secretary@ietf.org> To: IETF-Announce <ietf-announce@ietf.org> CC: ek.ietf@gmail.com, draft-ietf-6man-rfc4941bis@ietf.org, … The following Last Call announcement was sent out (ends 2020-09-23):<br><br>From: The IESG <iesg-secretary@ietf.org> To: IETF-Announce <ietf-announce@ietf.org> 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?= <otroan@employees.org>, ipv6@ietf.org Reply-To: last-call@ietf.org Sender: <iesg-secretary@ietf.org> Subject: Last Call: <draft-ietf-6man-rfc4941bis-10.txt> (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' <draft-ietf-6man-rfc4941bis-10.txt> 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 <narten@us.ibm.com>, Richard Draves <richdr@microsoft.com>, Fernando Gont <fgont@si6networks.com>, … Request for posting confirmation emailed to previous authors: 6man-chairs@ietf.org, Thomas Narten <narten@us.ibm.com>, Richard Draves <richdr@microsoft.com>, Fernando Gont <fgont@si6networks.com>, Suresh Krishnan <suresh.krishnan@ericsson.com> |
|
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 <fgont@si6networks.com>, Thomas Narten <narten@us.ibm.com>, Richard Draves <richdr@microsoft.com>, Suresh Krishnan … Request for posting confirmation emailed to previous authors: Fernando Gont <fgont@si6networks.com>, Thomas Narten <narten@us.ibm.com>, Richard Draves <richdr@microsoft.com>, Suresh Krishnan <suresh.krishnan@ericsson.com> |
|
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 <richdr@microsoft.com>, Thomas Narten <narten@us.ibm.com>, Suresh Krishnan <suresh.krishnan@ericsson.com>, Fernando Gont … Request for posting confirmation emailed to previous authors: Richard Draves <richdr@microsoft.com>, Thomas Narten <narten@us.ibm.com>, Suresh Krishnan <suresh.krishnan@ericsson.com>, Fernando Gont <fgont@si6networks.com> |
|
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 <narten@us.ibm.com>, Fernando Gont <fgont@si6networks.com>, Suresh Krishnan <suresh.krishnan@ericsson.com>, Richard Draves … Request for posting confirmation emailed to previous authors: Thomas Narten <narten@us.ibm.com>, Fernando Gont <fgont@si6networks.com>, Suresh Krishnan <suresh.krishnan@ericsson.com>, Richard Draves <richdr@microsoft.com> |
|
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 <fgont@si6networks.com>, Suresh Krishnan <suresh.krishnan@ericsson.com>, Richard Draves <richdr@microsoft.com>, Thomas Narten … Request for posting confirmation emailed to previous authors: Fernando Gont <fgont@si6networks.com>, Suresh Krishnan <suresh.krishnan@ericsson.com>, Richard Draves <richdr@microsoft.com>, Thomas Narten <narten@us.ibm.com> |
|
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 <fgont@si6networks.com>, Suresh Krishnan <suresh.krishnan@ericsson.com>, Richard Draves <richdr@microsoft.com>, Thomas Narten … Request for posting confirmation emailed to previous authors: Fernando Gont <fgont@si6networks.com>, Suresh Krishnan <suresh.krishnan@ericsson.com>, Richard Draves <richdr@microsoft.com>, Thomas Narten <narten@us.ibm.com> |
|
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 <fgont@si6networks.com>, Suresh Krishnan <suresh.krishnan@ericsson.com>, Richard Draves <richdr@microsoft.com>, Thomas Narten … Request for posting confirmation emailed to previous authors: Fernando Gont <fgont@si6networks.com>, Suresh Krishnan <suresh.krishnan@ericsson.com>, Richard Draves <richdr@microsoft.com>, Thomas Narten <narten@us.ibm.com> |
|
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 <fgont@si6networks.com>, Suresh Krishnan <suresh.krishnan@ericsson.com>, Richard Draves <richdr@microsoft.com>, Thomas Narten … Request for posting confirmation emailed to previous authors: Fernando Gont <fgont@si6networks.com>, Suresh Krishnan <suresh.krishnan@ericsson.com>, Richard Draves <richdr@microsoft.com>, Thomas Narten <narten@us.ibm.com> |
|
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 <fgont@si6networks.com>, Suresh Krishnan <suresh.krishnan@ericsson.com>, Richard Draves <richdr@microsoft.com>, Thomas Narten … Request for posting confirmation emailed to previous authors: Fernando Gont <fgont@si6networks.com>, Suresh Krishnan <suresh.krishnan@ericsson.com>, Richard Draves <richdr@microsoft.com>, Thomas Narten <narten@us.ibm.com> |
|
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 <fgont@si6networks.com>, Suresh Krishnan <suresh.krishnan@ericsson.com>, Richard Draves <richdr@microsoft.com>, Thomas Narten … Request for posting confirmation emailed to previous authors: Fernando Gont <fgont@si6networks.com>, Suresh Krishnan <suresh.krishnan@ericsson.com>, Richard Draves <richdr@microsoft.com>, Thomas Narten <narten@us.ibm.com> |
|
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 <fgont@si6networks.com>", 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 |