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 . . . . . . . . . . . . 5Why 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)?
-------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
