On 4/9/13 9:40 PM, Fernando Gont wrote:
Hi, Brian,
On 04/09/2013 12:21 PM, Brian Haberman wrote:
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.
I wasn't arguing in favor of them, but rather explaining what they were.
(FWIW, these notes predate our "discussion" on the subject... and, in
all fairness, you're not the first one to not like them :-) ).
I'll try to incorporate them into the main body -- fwiw, the reason for
which I including those paragraphs as such (parenthetical notes), is so
that the reader that is not interested in those details can easily skip
them.
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".
Yep, that was stupid -- how about s/for an interface index is likely to
change/for an interface will change/?
That should be fine.
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.
what's the "event" upon which the interface index will change?
"Interface removal", as in the suggested text, or something else?
My understanding is that some devices assign an ifIndex when the device
is activated (e.g., at boot time). Since device activation is
non-deterministic, an interface can get assigned a different ifIndex
each time it boots. To deal with this behavior, IOS has a "persist"
command that keeps state about each interfaces initial ifIndex.
If that's the case, I'd not expect that to happen frequently -- and even
less for hosts/servers doing SLAAC (those routers are more likely using
statically-configured addresses).
See above. I am not sure to what extent other platforms have a similar
issue.
Anyway... should I add something along this lines of:
"Some implementations are known to provide configuration knobs to set
the Interface Index for a given interface. This could be leveraged to
prevent maintain the same Interface Index for an interface when e.g. the
removal of a network interface causes Interface Indexes to change"
?
That should be sufficient.
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.
Me, I have no objections against that. I should note that DAD_Counter is
described in Section 4 because that section is the subject of a whole
topic. I guess we have two options:
1) Add a small sentence pointing to Section 4, or,
2) Move Section 4 into Section 3.
I'd probably go with 1), but wouldn't bother doing 2). -- Please pick
one, and I'll apply it.
Option (1) should be fine as long as that sentence in section 3 raises
awareness that DAD_Counter can change.
* 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*.
This is my rationale:
The internet architecture has no concept/namespace for "node". So, from
a practical point of view, different network interfaces all look like
different nodes (in the same way that you cannot use any of your
addresses for the same TCP connection, etc.).
That aside, you could also have the case where the same node connects to
the same network with two NICs, at the same time. In such scenario,
you're forced to have each NIC get a different IPv6 address. -- In a
scenario such as this, each NIC will get the same address (both in this
case and also when the node connects to that network with a single
interface).
Whoa... If two NICs on the same system connect to the same link, they
can't get the same address. Those two interfaces *should* have
different ifIndex values being fed into the PRF.
My comment above was meant to simply point out that these addresses are
per prefix/interface combination. That's all.
Regards,
Brian
So I'd argue that this is a desired property, rather than a drawback.
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".
Great.
Thanks!
Best regards,
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
