On 4/9/13 2:27 AM, Fernando Gont wrote:
Hi, Brian,
Thanks so much for the review! -- Please find my comments in-line...
On 04/08/2013 11:46 AM, Brian Haberman wrote:
1. Section 1 : I understand that the fourth paragraph is indented since
it is quoting from another document. I do not see why the fifth
paragraph is indented. The same confusion exists for the second
paragraph of Section 3.
Indented ṕararagraphs, unless otherwise noted, are parenthetical notes,
rather than quotes from other documents (i.e., text that provides
additional information, but that you may skip reading if you want).
We have had this discussion before... I am not a fan of these
parenthetical notes, but to each his own.
2. Section 3 :
* The PRF is fed several variables in order to generate a random number.
I appreciate that the issues with different identifiers being generated
for the same prefix due to varying values of DAD_Counter are discussed
(Section 4). What is missing is discussion of when the Interface_Index
value changes. On many systems, the value returned via the socket APIs
is based on the ifIndex value assigned to the interface. There are a
variety of situations where the ifIndex can change within a system and
these should be mentioned. This can impact design goal #2.
HOw about the following text:
"The Interface Index is expected to remain constant across system
reboots and other events. However, we note that it might change upon
removal of a network interface (typically one with a smaller value for
the Interface Index, when such naming scheme is used). When such
Interface Index changes occur, the IPv6 addresses resulting from this
algorithm for an interface index is likely to change, thus affecting the
stability property of this approach. We note that we expect these
scenarios to be unusual."
I don't like "likely to change". In what cases would a change to an
input value *not* change the output of the PRF?
Additionally, I will note that this scenario may not be as unusual as
you think. For example, the ifIndex on some Cisco gear will change
enough that IOS has a configuration command to make it stable.
Maybe in the corresponding "bullet"? Or right after the paragraph that
says "Including the SLAAC prefix in the PRF computation causes the..."?
The latter would be preferable, but it raises another question. If
there is discussion on input values changing in section 3, the text on
the impact of DAD_Counter changes in section 4 should probably be moved
to section 3.
* What are the assumptions on this algorithm with respect to multi-homed
devices that could have different network interfaces available to attach
to the same network? For example, if I have a quad-port network card, I
could attach to a network via eth0 and get an identifier for prefix X.
The next time I attach to that network, I use eth2 and I will not get
the same identifier even though I still get a PIO containing prefix X.
This issue directly contradicts design goal #1.
This algorithm aims to produce stable addresses for each interface. SO
as long as the same interface gets the same addresses, the algorithm is
achieving it's goal.
Then something needs to be said in the document about this limitation.
This approach does not create stable addresses *per prefix*.
3. I think it would be good to explicitly state that this IID generation
mechanism is incrementally deployable since there are no
interoperability issues with IID generation.
Good point.
How about adding this to the Intro, right after the para that starts
with "This document specifies a method to generate interface
identifiers...":
"We note that this method is is incrementally deployable, since it
doesn't pose any interoperability implications when deployed on networks
where other nodes do not implement or employ it".
?
The above is fine as long as you remove the redundant "is".
Regards,
Brian
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
