Hi Margaret,
Thanks for the comments and the text. I have submitted version -04 of
the draft with the suggested changes. Let me know if you have any more
issues you would like me to address.
Cheers
Suresh
On Fri, 13 May 2005, Margaret Wasserman wrote:
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
[email protected]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
