Privacy Extensions for Stateless Address Autoconfiguration in IPv6
RFC 4941
Revision differences
Document history
| Date | Rev. | By | Action |
|---|---|---|---|
|
2020-01-21
|
05 | (System) | Received changes through RFC Editor sync (added Verified Errata tag) |
|
2015-10-14
|
05 | (System) | Notify list changed from ipv6-chairs@ietf.org, narten@raleigh.ibm.com, suresh.krishnan@ericsson.com, brian@innovationslab.net, richdr@microsoft.com to (None) |
|
2012-08-22
|
05 | (System) | post-migration administrative database adjustment to the No Objection position for Cullen Jennings |
|
2012-08-22
|
05 | (System) | post-migration administrative database adjustment to the No Objection position for Bill Fenner |
|
2012-08-22
|
05 | (System) | post-migration administrative database adjustment to the No Objection position for Ted Hardie |
|
2012-08-22
|
05 | (System) | post-migration administrative database adjustment to the No Objection position for Russ Housley |
|
2007-09-26
|
05 | Amy Vezza | State Changes to RFC Published from RFC Ed Queue by Amy Vezza |
|
2007-09-26
|
05 | Amy Vezza | [Note]: 'RFC 4941' added by Amy Vezza |
|
2007-09-24
|
05 | (System) | RFC published |
|
2006-11-15
|
05 | Amy Vezza | State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza |
|
2006-11-04
|
05 | Amy Vezza | IESG state changed to Approved-announcement sent |
|
2006-11-04
|
05 | Amy Vezza | IESG has approved the document |
|
2006-11-04
|
05 | Amy Vezza | Closed "Approve" ballot |
|
2006-11-04
|
05 | Amy Vezza | State Changes to Approved-announcement to be sent from IESG Evaluation::AD Followup by Amy Vezza |
|
2006-11-01
|
05 | Jari Arkko | State Changes to IESG Evaluation::AD Followup from IESG Evaluation - Defer by Jari Arkko |
|
2006-10-30
|
05 | Cullen Jennings | [Ballot Position Update] Position for Cullen Jennings has been changed to No Objection from Discuss by Cullen Jennings |
|
2006-10-30
|
05 | Cullen Jennings | Any update on what the plan is to move forward on resolving the interoperability report issue? |
|
2006-10-17
|
05 | Bill Fenner | [Ballot Position Update] Position for Bill Fenner has been changed to No Objection from Discuss by Bill Fenner |
|
2006-10-09
|
05 | Russ Housley | [Ballot Position Update] Position for Russ Housley has been changed to No Objection from Discuss by Russ Housley |
|
2006-10-09
|
05 | (System) | New version available: draft-ietf-ipv6-privacy-addrs-v2-05.txt |
|
2006-10-09
|
05 | Cullen Jennings | [Ballot discuss] I am not finding the interoperability report needed to advance this. |
|
2006-10-09
|
05 | Cullen Jennings | [Ballot discuss] I'm sure I am behind the times and just not finding this, but I am not finding the interoperability report needed to advance … [Ballot discuss] I'm sure I am behind the times and just not finding this, but I am not finding the interoperability report needed to advance this. |
|
2006-10-09
|
05 | Cullen Jennings | [Ballot comment] Authors sent me the following explanation of the algorithm which I found much easier to follow. You might want to consider adding something … [Ballot comment] Authors sent me the following explanation of the algorithm which I found much easier to follow. You might want to consider adding something like this in the early part of the security section. It is not easy to predict the next address which will be used because the history value is not externally visible. First the node generates a 128 bit MD5 hash, say RES, using a random initial value. Let's assume a function FIRSTx(foo) which returns the first x bits of foo and LASTx(foo) which returns the last x bits of foo. The algorithm described in the document uses FIRST64(RES) as the interface identifier(setting bit 6 to 0) and stores LAST64(RES) as the history value for the next iteration. Since LAST64(RES) is not cryptographically related to FIRST64(RES), it will not be possible to guess HASH(LAST64(RES)) knowing just FIRST64(RES). |
|
2006-10-09
|
05 | Cullen Jennings | State Change Notice email list have been change to ipv6-chairs@tools.ietf.org, narten@raleigh.ibm.com, suresh.krishnan@ericsson.com, brian@innovationslab.net, richdr@microsoft.com from ipv6-chairs@tools.ietf.org |
|
2006-10-09
|
05 | Jari Arkko | State Changes to IESG Evaluation - Defer from IESG Evaluation::Revised ID Needed by Jari Arkko |
|
2006-08-25
|
05 | Jari Arkko | Some ongoing discussion on the IPv6 list about additional issues in the draft. This is likely to result in a need to revise. |
|
2006-08-23
|
05 | Jari Arkko | State Change Notice email list have been change to ipv6-chairs@tools.ietf.org from bob.hinden@nokia.com, brian@innovationslab.net |
|
2006-08-23
|
05 | Jari Arkko | [Note]: 'PROTO shepherd is Brian Haberman <brian@innovationslab.net>.' added by Jari Arkko |
|
2006-08-15
|
05 | Jari Arkko | State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation::External Party by Jari Arkko |
|
2006-08-15
|
05 | Jari Arkko | I reviewed the changes in a pre-version of draft -05. They looked good, but there was one editorial suggestion and one question. Expecting the authors … I reviewed the changes in a pre-version of draft -05. They looked good, but there was one editorial suggestion and one question. Expecting the authors to fix/respond and resubmit. All discusses have been addressed as far as I can see, including Cullen's. |
|
2006-08-08
|
05 | Ted Hardie | [Ballot Position Update] Position for Ted Hardie has been changed to No Objection from Discuss by Ted Hardie |
|
2006-07-30
|
05 | Jari Arkko | Implementation report for Linux (vs. Windows and FreeBSD) has been received and has been sent to the secretariat. |
|
2006-07-30
|
05 | Jari Arkko | [Note]: 'PROTO shepherd is Brian Haberman <brian@innovationslab.net>.' added by Jari Arkko |
|
2006-07-30
|
05 | Jari Arkko | 3/9/06: Needs an updated implementation report before it can proceed. |
|
2006-07-11
|
05 | Russ Housley | [Ballot discuss] Section 3.2.1 says: > > MD5 was chosen for convenience, and because its particular properties > were adequate to produce … [Ballot discuss] Section 3.2.1 says: > > MD5 was chosen for convenience, and because its particular properties > were adequate to produce the desired level of randomization. IPv6 > nodes are already required to implement MD5 as part of IPsec [IPSEC], > thus the code will already be present on IPv6 machines. > I see no requirement for MD5 in IPsec. I have agreed to the following text on 11-July-2006 as a solution to this concern: > > MD5 was chosen for convenience, and because its particular properties > were adequate to produce the desired level of randomization. The node > MAY use another algorithm instead of MD5 to produce the random > interface identifier. |
|
2006-06-05
|
05 | Jari Arkko | 5/6/06: Pinged chairs about the status. |
|
2006-05-31
|
05 | Magnus Westerlund | [Ballot Position Update] New position, No Objection, has been recorded for Magnus Westerlund by Magnus Westerlund |
|
2006-05-31
|
05 | Dan Romascanu | [Ballot Position Update] New position, No Objection, has been recorded for Dan Romascanu by Dan Romascanu |
|
2006-05-27
|
05 | Cullen Jennings | [Ballot discuss] Ok - I am going to enter a discuss here where I am 99% sure the answer is going to be Cullen you … [Ballot discuss] Ok - I am going to enter a discuss here where I am 99% sure the answer is going to be Cullen you are totally confused, go read the document but if that is the case it will be easy to clear. In section 3, point #3, we have as a requirement that if an attacker knows the current address, it is not easy to predict a future address. I agree this is the fundamental requirement. However I'm not sure I see how the history algorithm in section 3.2.1 does this. It seems that if you use address X, then X gets stored in the history. The next address will used will be MD5(X). It seems the attacker can predict this. Now I am sure that I must just be confused on what is happening here so straighten me out. The storage algorithm never seems to add any new randomness in and the initially randomness has high odds of being really crappy because the entropy available to many devices the first time they boot is really low and often has bad problems based on implementers making very bad assumptions about what is random in systems that are basically highly deterministic by nature. I'm sure I am behind the times and just not finding this, but I am not finding the interoperability report needed to advance this. |
|
2006-05-27
|
05 | Cullen Jennings | [Ballot discuss] Ok - I am going to enter a discuss here where I am 99% sure the answer is going to be Cullen you … [Ballot discuss] Ok - I am going to enter a discuss here where I am 99% sure the answer is going to be Cullen you are totally confused, go read the document but if that is the case it will be easy to clear. In section 3, point #3, we have as a requirement that if an attacker knows the current address, it is not easy to predict a future address. I agree this is the fundamental requirement. However I'm not sure I see how the history algorithm in section 3.2.1 does this. It seems that if you use address X, then X gets stored in the history. The next address will used will be MD5(X). It seems the attacker can predict this. Now I am sure that I must just be confused on what is happening here so straighten me out. The storage algorithm never seems to add any new randomness in and the initially randomness has high odds of being really crappy because the entropy available to many devices the first time they boot is really low and often has bad problems based on implementers making very bad assumptions about what is random in systems that are basically highly deterministic by nature. I'm sure I am behind the times and just not finding this, but I am not finding the interoperability report needed to advance this. |
|
2006-05-27
|
05 | Cullen Jennings | [Ballot Position Update] Position for Cullen Jennings has been changed to Discuss from Undefined by Cullen Jennings |
|
2006-05-25
|
05 | Cullen Jennings | [Ballot Position Update] New position, Undefined, has been recorded for Cullen Jennings by Cullen Jennings |
|
2006-03-25
|
05 | Margaret Cullen | Shepherding AD has been changed to Jari Arkko from Margaret Wasserman |
|
2006-03-09
|
05 | Margaret Cullen | State Changes to IESG Evaluation::External Party from IESG Evaluation::AD Followup by Margaret Wasserman |
|
2006-03-09
|
05 | Margaret Cullen | [Note]: 'PROTO shepherd is Brian Haberman <brian@innovationslab.net>. 3/9/06: Needs an updated implementation report before it can proceed.' added by Margaret Wasserman |
|
2005-12-16
|
05 | (System) | Removed from agenda for telechat - 2005-12-15 |
|
2005-12-15
|
05 | Amy Vezza | State Changes to IESG Evaluation::AD Followup from IESG Evaluation by Amy Vezza |
|
2005-12-15
|
05 | (System) | [Ballot Position Update] New position, yes, has been recorded for Allison Mankin by IESG Secretary |
|
2005-12-15
|
05 | Alex Zinin | [Ballot Position Update] New position, No Objection, has been recorded for Alex Zinin by Alex Zinin |
|
2005-12-15
|
05 | Ted Hardie | [Ballot discuss] Update: The KAME and Windows implementation reports do not appear to cover quite the same ground. There is at least one section (3.2) … [Ballot discuss] Update: The KAME and Windows implementation reports do not appear to cover quite the same ground. There is at least one section (3.2) for which implementation is not in both. In general, I think we need an interoperability report bundling these implementation reports, so that we have someone saying that the two implementations interoperate and how that interoperability was determined. old: As Scott points out in his comments, this report only has a single implementation report, Dave Thaler's from Microsoft. I think we need two for the implementation report to be sufficient for DS. |
|
2005-12-15
|
05 | Brian Carpenter | [Ballot comment] Fully agree with Scott and Ted that we lack a sufficient interop report. It seems that the KAME FreeBSD report was not posted. … [Ballot comment] Fully agree with Scott and Ted that we lack a sufficient interop report. It seems that the KAME FreeBSD report was not posted. Its core: A. Lifetime Management (Section 3.4) Verified proper Lifetime Management behavior with Router Advertisements generated by Cisco and Juniper IPv6 routers. B. DAD Operation (Section 3.3) Verified the creation of a temporary address (which is to be unique on the link) and the performance of DAD on that address without disrupting other implementations. This was tested with various implementations from different origins including Linux and Solaris 10. |
|
2005-12-15
|
05 | Mark Townsley | [Ballot Position Update] New position, No Objection, has been recorded for Mark Townsley by Mark Townsley |
|
2005-12-15
|
05 | Bert Wijnen | [Ballot discuss] - I agree with other IESG members, that the single implementation report is not sufficient to show INTEROPERABILITY between multiple (at least … [Ballot discuss] - I agree with other IESG members, that the single implementation report is not sufficient to show INTEROPERABILITY between multiple (at least 2) genetically independent implementations - I think it should be made clear that this doc obsoletes RFC3041 - I see that several "additions" were made (section 7) on top of what is in RFC3041. So does that allow to advance to DS, or would it be better to recycle at PS. Specifically since we only see a report of a single implementation. |
|
2005-12-15
|
05 | Bert Wijnen | [Ballot Position Update] New position, Discuss, has been recorded for Bert Wijnen by Bert Wijnen |
|
2005-12-15
|
05 | Jon Peterson | [Ballot Position Update] New position, No Objection, has been recorded for Jon Peterson by Jon Peterson |
|
2005-12-15
|
05 | Brian Carpenter | [Ballot comment] Fully agree with Scott and Ted that we lack a sufficient interop report. |
|
2005-12-15
|
05 | Brian Carpenter | [Ballot Position Update] New position, No Objection, has been recorded for Brian Carpenter by Brian Carpenter |
|
2005-12-15
|
05 | Bill Fenner | [Ballot comment] Don't forget to put the "Obsoletes RFC 3041" metadata in the note to the RFC Editor. |
|
2005-12-15
|
05 | Bill Fenner | [Ballot discuss] Section 6 ends with a mini "Open Issues" section that wasn't in RFC 3041. I don't think a Draft Standard should have … [Ballot discuss] Section 6 ends with a mini "Open Issues" section that wasn't in RFC 3041. I don't think a Draft Standard should have new open issues. |
|
2005-12-15
|
05 | Bill Fenner | [Ballot Position Update] New position, Discuss, has been recorded for Bill Fenner by Bill Fenner |
|
2005-12-14
|
05 | Ted Hardie | [Ballot discuss] As Scott points out in his comments, this report only has a single implementation report, Dave Thaler's from Microsoft. I think we need … [Ballot discuss] As Scott points out in his comments, this report only has a single implementation report, Dave Thaler's from Microsoft. I think we need two for the implementation report to be sufficient for DS. |
|
2005-12-14
|
05 | Ted Hardie | [Ballot Position Update] New position, Discuss, has been recorded for Ted Hardie by Ted Hardie |
|
2005-12-14
|
05 | Scott Hollenbeck | [Ballot comment] Implementation report: http://www.ietf.org/IESG/Implementations/implementation-rfc-3041.txt This report only describes one implementation. A description of how this implementation interoperates with a second independently developed implementation is … [Ballot comment] Implementation report: http://www.ietf.org/IESG/Implementations/implementation-rfc-3041.txt This report only describes one implementation. A description of how this implementation interoperates with a second independently developed implementation is needed. Is this document intended to obsolete RFC 3041? Section 7 makes it appear so, but some text in the front page header and the abstract would make the situation more obvious if that's the intention. |
|
2005-12-14
|
05 | Scott Hollenbeck | [Ballot Position Update] New position, Abstain, has been recorded for Scott Hollenbeck by Scott Hollenbeck |
|
2005-12-13
|
05 | Russ Housley | [Ballot comment] Please delete sections 8 thru 11 prior to publication. |
|
2005-12-13
|
05 | Russ Housley | [Ballot discuss] Section 3.2.1 says: > > MD5 was chosen for convenience, and because its particular properties > were adequate to produce … [Ballot discuss] Section 3.2.1 says: > > MD5 was chosen for convenience, and because its particular properties > were adequate to produce the desired level of randomization. IPv6 > nodes are already required to implement MD5 as part of IPsec [IPSEC], > thus the code will already be present on IPv6 machines. > I see no requirement for MD5 in RFC 2401. I do not see one in the soon-to-be-published 2401bis either. I also looked in draft-ietf-ipsec-esp-ah-algorithms-02, and all MD5-related algorithms are MAY implement. I do not see a problem with MD5 in this case, but I think this rationale is incorrect today. It may have been correct when RFC 3041 was published. |
|
2005-12-13
|
05 | Russ Housley | [Ballot Position Update] New position, Discuss, has been recorded for Russ Housley by Russ Housley |
|
2005-12-13
|
05 | Sam Hartman | [Ballot Position Update] New position, No Objection, has been recorded for Sam Hartman by Sam Hartman |
|
2005-12-12
|
05 | Margaret Cullen | [Note]: 'PROTO shepherd is Brian Haberman <brian@innovationslab.net>.' added by Margaret Wasserman |
|
2005-12-08
|
05 | Margaret Cullen | State Changes to IESG Evaluation from AD is watching by Margaret Wasserman |
|
2005-12-08
|
05 | Margaret Cullen | Placed on agenda for telechat - 2005-12-15 by Margaret Wasserman |
|
2005-12-08
|
05 | Margaret Cullen | Note field has been cleared by Margaret Wasserman |
|
2005-12-07
|
05 | Dinara Suleymanova | State Changes to AD is watching from Dead by Dinara Suleymanova |
|
2005-12-07
|
05 | (System) | This document has been resurrected. |
|
2005-12-03
|
05 | (System) | State Changes to Dead from AD is watching by system |
|
2005-12-03
|
05 | (System) | Document has expired |
|
2005-09-21
|
05 | Michelle Cotton | IANA Comments: NO IANA Considerations section. We understand this document to have NO IANA Actions. |
|
2005-08-15
|
05 | Margaret Cullen | Removed from agenda for telechat - 2005-08-18 by Margaret Wasserman |
|
2005-08-15
|
05 | Margaret Cullen | State Changes to AD is watching from IESG Evaluation by Margaret Wasserman |
|
2005-08-15
|
05 | Margaret Cullen | [Note]: 'Back to the WG for clarification on whether this should be published as PS or DS (which would require an interoperability report).' added by … [Note]: 'Back to the WG for clarification on whether this should be published as PS or DS (which would require an interoperability report).' added by Margaret Wasserman |
|
2005-08-10
|
05 | Margaret Cullen | [Ballot Position Update] New position, Yes, has been recorded for Margaret Wasserman |
|
2005-08-10
|
05 | Margaret Cullen | Ballot has been issued by Margaret Wasserman |
|
2005-08-10
|
05 | Margaret Cullen | Created "Approve" ballot |
|
2005-08-10
|
05 | Margaret Cullen | State Changes to IESG Evaluation from Waiting for Writeup by Margaret Wasserman |
|
2005-08-10
|
05 | Margaret Cullen | Placed on agenda for telechat - 2005-08-18 by Margaret Wasserman |
|
2005-08-01
|
05 | (System) | State has been changed to Waiting for Writeup from In Last Call by system |
|
2005-07-18
|
05 | Amy Vezza | Last call sent |
|
2005-07-18
|
05 | Amy Vezza | State Changes to In Last Call from Last Call Requested by Amy Vezza |
|
2005-07-17
|
05 | Margaret Cullen | State Changes to Last Call Requested from AD Evaluation::AD Followup by Margaret Wasserman |
|
2005-07-17
|
05 | Margaret Cullen | Last Call was requested by Margaret Wasserman |
|
2005-07-17
|
05 | (System) | Ballot writeup text was added |
|
2005-07-17
|
05 | (System) | Last call text was added |
|
2005-07-17
|
05 | (System) | Ballot approval text was added |
|
2005-07-17
|
05 | Margaret Cullen | Note field has been cleared by Margaret Wasserman |
|
2005-05-25
|
05 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
|
2005-05-25
|
04 | (System) | New version available: draft-ietf-ipv6-privacy-addrs-v2-04.txt |
|
2005-05-22
|
05 | Margaret Cullen | More on AD Review Comments: Date: Fri, 13 May 2005 13:50:39 -0400 To: Suresh Krishnan <suresh.krishnan@ericsson.ca> From: Margaret Wasserman <margaret@thingmagic.com> Cc: … More on AD Review Comments: Date: Fri, 13 May 2005 13:50:39 -0400 To: Suresh Krishnan <suresh.krishnan@ericsson.ca> From: Margaret Wasserman <margaret@thingmagic.com> Cc: ipv6@ietf.org Subject: Re: AD Review comments on draft-ietf-ipv6-privacy-addrs-v2-03 At 10:15 AM -0400 5/11/05, Suresh Krishnan wrote: >> 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 >> 1.1 Problem Statement . . . . . . . . . . . . . . . . . . . . 5 >> 1.2 Conventions used in this document . . . . . . . . . . . . 5 >> >>>> Why is the RFC 2119 section inside the problem statement? > >It is just another sub section under introduction to the document and is not under the problem statement. I can move this to a separate section if you feel strongly about this. Oh, okay... I viewed the Problem Statement and the Background both as parts of the problem statement. Maybe if you just switched the order of 1.1 and 1.2 (so the RFC 2119 language comes first), that would be better. Or, just ignore this issue, as it is purely editorial. >> 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 6 >> 2.1 Extended Use of the Same Identifier . . . . . . . . . . . 6 >> 2.2 Address Usage in IPv4 Today . . . . . . . . . . . . . . . 7 >> 2.3 The Concern With IPv6 Addresses . . . . . . . . . . . . . 8 >> 2.4 Possible Approaches . . . . . . . . . . . . . . . . . . . 9 >> >>>> Is section 2 supposed to be part of the problem statement? > >The problem statement is a concise description of the threat model we are defending against. Section 2 is a much more detailed study of the problems involved. The problem statement was created to provide the reader with some context as to why the document is needed. So the problem statement is a summary of sorts of section 2. Okay. >> 3. Protocol Description >> >> The goal of this section is to define procedures that: >> >> 1. Do not result in any changes to the basic behavior of addresses >> generated via stateless address autoconfiguration [ADDRCONF]. >> 2. Create additional global scope addresses based on a random >> interface identifier for use with global scope addresses. >> >>>> What is meant by "for use with global addresses"? is this intended >> to be a restriction on how/when privacy addresses can be used? > >This is not an intended restriction. I can reword it to read > >"2. Create additional addresses based on a random interface identifier for > the purpose of initiating outgoing sessions" > >instead of > >"2. Create additional global scope addresses based on a random > interface identifier for use with global scope addresses.Such > addresses would be used to initiate outgoing sessions." > >Does that sound OK? Yes, that is better. >> 3.1 Assumptions >> >> The following algorithm assumes that each interface maintains an >> associated randomized interface identifier. When temporary addresses >> are generated, the current value of the associated randomized >> interface identifier is used. The actual value of the identifier >> changes over time as described below, but the same identifier can be >> used to generate more than one temporary address. >> >> The algorithm also assumes that for a given temporary address, an >> implementation can determine the prefix from which it was generated. >> When a temporary address is deprecated, a new temporary address is >> generated. The specific valid and preferred lifetimes for the new >> address are dependent on the corresponding lifetime values set for >> the prefix from which it was generated. >> >>>> These two paragraphs are confusing to me. The node maintains a >> random IID from which multiple addresses can be generated of the >> form <prefix, IID>, right? These addresses will become deprecated >> when their lifetime expires, and new addresses will be generated. >> The implementation keeps track of what prefix was used to generate >> the addres and generates a new address for that prefix, right? >> Does it also need to generate a new random IID when this happens? >> In other words, is there anything in this mechanism that prevents >> generating the same privacy address again on the same interface >> using the same prefix and the same random IID (if it hasn't expired >> yet)? > >The mechanism certainly allows this behavior but it kind of defeats the purpose(to not have a stable interface identifier). The requirement to change the random interface identifier is a SHOULD and is described in section 3.5 > >" Nodes following this specification SHOULD generate new temporary > addresses on a periodic basis. This can be achieved automatically by > generating a new randomized interface identifier at least once every > (TEMP_PREFERRED_LIFETIME - REGEN_ADVANCE - DESYNC_FACTOR) time units." > >If you think this is should be a stronger requirement I can change it to a MUST at the cost of breaking backward compatibility. Let me know what you prefer. The SHOULD is fine, but perhaps you could change the first paragraph of section 3.1 to read: The following algorithm assumes that each interface maintains an associated randomized interface identifier. When temporary addresses are generated, the current value of the associated randomized interface identifier is used. While the same identifier can be used to create more than one temporary address, the value SHOULD change over time as described in section 3.5. This would make it clearer that a person should look at section 3.5 to understand how the identifier will change over time. Margaret -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- |
|
2005-05-22
|
05 | Margaret Cullen | [Note]: 'Waiting for (minor) document updates to address AD Review comments (see below).' added by Margaret Wasserman |
|
2005-05-22
|
05 | Margaret Cullen | AD Review comments sent to IPv6 WG: To: ipv6@ietf.org From: Margaret Wasserman <margaret@thingmagic.com> Subject: AD Review comments on draft-ietf-ipv6-privacy-addrs-v2-03 Cc: Hi All, I … AD Review comments sent to IPv6 WG: To: ipv6@ietf.org From: Margaret Wasserman <margaret@thingmagic.com> Subject: AD Review comments on draft-ietf-ipv6-privacy-addrs-v2-03 Cc: Hi All, I have a few AD Review comments on draft-ietf-ipv6-privacy-addrs-v2-03 that I would like to have resolved before I send this document to IETF LC. I've included those comments below. Brian and Bob, the tracker indicates that this document is intended for publication as a Draft Standard, however RFC 3041 is currently at PS, and this document seems to contain some changes to the specification that would impact implementations (such as the requirement to perform DAD on all generated addresses). Is the tracker state correct? If so, what is the rationale for publishing this document at DS? Thanks, Margaret >> I think that sometihng went wrong with the structure of this document: Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1 Problem Statement . . . . . . . . . . . . . . . . . . . . 5 1.2 Conventions used in this document . . . . . . . . . . . . 5 >> Why is the RFC 2119 section inside the problem statement? 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.1 Extended Use of the Same Identifier . . . . . . . . . . . 6 2.2 Address Usage in IPv4 Today . . . . . . . . . . . . . . . 7 2.3 The Concern With IPv6 Addresses . . . . . . . . . . . . . 8 2.4 Possible Approaches . . . . . . . . . . . . . . . . . . . 9 >> Is section 2 supposed to be part of the problem statement? 3. Protocol Description The goal of this section is to define procedures that: 1. Do not result in any changes to the basic behavior of addresses generated via stateless address autoconfiguration [ADDRCONF]. 2. Create additional global scope addresses based on a random interface identifier for use with global scope addresses. >> What is meant by "for use with global addresses"? is this intended to be a restriction on how/when privacy addresses can be used? 3.1 Assumptions The following algorithm assumes that each interface maintains an associated randomized interface identifier. When temporary addresses are generated, the current value of the associated randomized interface identifier is used. The actual value of the identifier changes over time as described below, but the same identifier can be used to generate more than one temporary address. The algorithm also assumes that for a given temporary address, an implementation can determine the prefix from which it was generated. When a temporary address is deprecated, a new temporary address is generated. The specific valid and preferred lifetimes for the new address are dependent on the corresponding lifetime values set for the prefix from which it was generated. >> These two paragraphs are confusing to me. The node maintains a random IID from which multiple addresses can be generated of the form <prefix, IID>, right? These addresses will become deprecated when their lifetime expires, and new addresses will be generated. The implementation keeps track of what prefix was used to generate the addres and generates a new address for that prefix, right? Does it also need to generate a new random IID when this happens? In other words, is there anything in this mechanism that prevents generating the same privacy address again on the same interface using the same prefix and the same random IID (if it hasn't expired yet)? |
|
2005-05-10
|
05 | Margaret Cullen | State Changes to AD Evaluation::Revised ID Needed from Publication Requested by Margaret Wasserman |
|
2005-04-19
|
05 | Dinara Suleymanova | Draft Added by Dinara Suleymanova in state Publication Requested |
|
2005-04-05
|
03 | (System) | New version available: draft-ietf-ipv6-privacy-addrs-v2-03.txt |
|
2004-12-28
|
02 | (System) | New version available: draft-ietf-ipv6-privacy-addrs-v2-02.txt |
|
2004-10-25
|
01 | (System) | New version available: draft-ietf-ipv6-privacy-addrs-v2-01.txt |
|
2004-09-22
|
00 | (System) | New version available: draft-ietf-ipv6-privacy-addrs-v2-00.txt |