Hi, Brian, On 04/10/2013 07:01 PM, Brian Haberman wrote: >>> 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.
I've not experienced that myself. That said, I'd probably argue that such changes are probably annoying for there reasons: I guess that if the interface index changes, so does the usual suffix in the interface name (e.g. ethN, wlanN) -- hence delaying with link-local addresses would become more painful than necessary. >> 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. I've not experienced this in Windows, *BSD, or Linux, at least. >>>> 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. Done. >>> 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. Exactly. my pint was that this is the very reason for which one cannot expect two different NICs to get the same IPv6 addresses when they connect (separately) to the same network. > My comment above was meant to simply point out that these addresses are > per prefix/interface combination. That's all. Agreed. Should I tweak the document n any way regarding this? Thanks! Best regards, -- Fernando Gont e-mail: ferna...@gont.com.ar || fg...@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
