Hi Margaret, Thanks for the comments. Please see my replies inline.
Thanks Suresh
On Tue, 10 May 2005, Margaret Wasserman wrote:
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?
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.
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.
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.
to be a restriction on how/when privacy addresses can be used?What is meant by "for use with global addresses"? is this intended
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?
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 arandom 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.
-------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
