|
Hi Fernando,
I would like to make some last comments about your draft, which i fully support. First of all, i would like to see a reference to cases where the prefix doesn't change too often (since this is recommended by many people for various deployments, i.e. residential dsl) due to mostly renumbering issues. In this case, Privacy Extensions seem to offer an advantage in terms of host tracking. Also, it would be good to include some examples of IIDs produced by an implementation of the proposed algorithm, taking into account various scenarios with common parameters. Lastly, in a comment i had made back in March 2012 regarding your draft and source address selection, and now looking at current rfc6724 i can see the following: Rule 7: Prefer temporary addresses. If SA is a temporary address and SB is a public address, then prefer SA. Similarly, if SB is a temporary address and SA is a public address, then prefer SB. Although the implementations must provide a mechanism allowing an application to reverse this, if the above is the default behavior meaning that if privacy extensions are enabled, temporary addresses will have preference over your stable addresses, then i think the following 2 paragraphs don't apply anymore in your draft. Please correct me if i'm wrong. On the other hand, in scenarios in which "Privacy Extensions" are employed, implementation of the mechanism described in this document would mitigate host-scanning attacks and also mitigate correlation of host activities. On the other hand, in the case of hosts employing "Privacy Extensions", the method specified in this document would prevent host scanning attacks and correlation of node activities across networks (see Appendix A). ...and some editorial comments... The resulting interface identifiers remain constant/stable for
each prefix used with SLAAC within each subnet. That is, the
algorithm generates the same interface identifier when configuring
an address belonging to the same prefix within the same subnet.within the same subnet. => within the same subnet (assuming parameters defined in Section 3 remain the same). 2. The Interface Identifier is finally obtained by taking the
leftmost 64 bits of the RID value computed in the previous step,
and and setting bit 6 (the leftmost bit is numbered 0) to zero.
and and => andThe resulting Interface
Identifier should be compared against a list of reserved
interface identifiers and to those already employed in an address
of the same network interface and the same network prefix. In
the event that an unacceptable identifier has been generated,
this situation should be handled in the same way as the case of
duplicate addresses
employed in an address of the same network interface and the same
network prefix = > employed in an address of another host
through the same local network interface and using the same
network prefixIn the event that an unacceptable identifier has been generated => In the event that such an identifier has been generated Also if "a list of reserved identifiers" refers to http://www.iana.org/assignments/ipv6-interface-ids/ipv6-interface-ids.xml, then it should probably be "the list of...". Unless, we assume everyone is allowed to use its own list of reserved identifiers. In the event that a DAD conflict cannot be solved (possibly after trying a number of different addresses), address configuration would fail. In those scenarios, nodes MUST NOT automatically fall back to employing other algorithms for generating interface identifiers.Shouldn't an error message be logged somewhere? This document does not require the use of any specific PRF for the function F() above, since the choice of such PRF is usually a trade- off between a number of properties (processing requirements, ease of implementation, possible intellectual property rights, etc.), and since the best possible choice for F() might be different for different types of devices (e.g. embedded systems vs. regular servers) and might possibly change over time.and might possibly change over time => it might possibly change over time since it would mitigate host- tracking vectors still present when privacy addresses are used (Appendix A,(Appendix A, => (Appendix A), -- TassosFernando Gont wrote on 17/1/2013 20:11: Folks, Is the I-D ready to ship? It has been weeks since I posted the last rev. My understanding is that this I-D is ready to ship (after the clarifications I made on-list, and the tweaks I made to the I-D). But if there's any remaining bit, I'd like to know. But if the RTTs for these exchanges get so long, it's becomes even harder to follow the discussions. I'm aware that there are folks working on implementations of this I-D, and it'd be great to progress this I-D sooner than later. Thanks! Best regards, Fernando On 01/11/2013 06:16 AM, Fernando Gont wrote:Bob & Ole, Ping? Thanks, Fernando On 12/29/2012 10:18 PM, Fernando Gont wrote:Folks, I've rev'ed the document according to our recent email exchange. Should we ship the document now? Thanks, and have a Happy New Year! Best regards, Fernando On 12/29/2012 10:15 PM, internet-dra...@ietf.org wrote:A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Maintenance Working Group of the IETF. Title : A method for Generating Stable Privacy-Enhanced Addresses with IPv6 Stateless Address Autoconfiguration (SLAAC) Author(s) : Fernando Gont Filename : draft-ietf-6man-stable-privacy-addresses-02.txt Pages : 18 Date : 2012-12-29 Abstract: This document specifies a method for generating IPv6 Interface Identifiers to be used with IPv6 Stateless Address Autoconfiguration (SLAAC), such that addresses configured using this method are stable within each subnet, but the Interface Identifier changes when hosts move from one network to another. The aforementioned method is meant to be an alternative to generating Interface Identifiers based on IEEE identifiers, such that the benefits of stable addresses can be achieved without sacrificing the privacy of users. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-6man-stable-privacy-addresses There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-6man-stable-privacy-addresses-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-6man-stable-privacy-addresses-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- |
-------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
