---- Original Message ----- From: "Fernando Gont" <fg...@si6networks.com> To: <6...@ietf.org> Cc: <6man-cha...@tools.ietf.org>; "RJ Atkinson" <rja.li...@gmail.com>; "Brian Haberman" <br...@innovationslab.net>; "t.petch" <daedu...@btconnect.com> Sent: Thursday, April 25, 2013 3:01 PM
> Folks, > > During IETF LC, a couple of folks noted that Interface Indexes might not > be stable. > > I added some text on the subject to my working copy (mostly based on the > discussion with Brian Haberman and Mark Smith), but the issue came up > again (Tom Petch commented on the subject). > > Since the raison d'etre for including the Interface Index in F() is to > differentiate between multiple interfaces connecting to the same > network, either the Interface Index or the Interface Name could be used. > So far, these are the pros/cons of each: > > * Interface Index: Including this one would be ideal, since it's simply > a small number that identifies the interface, and does not really depend > on the NIC vendor, etc. However, as noted above, in some implementations > it might be unstable (i.e., vary when the system is bootstrapped). > > * Interface name: This one has the pro that is stable, even on systems > in which the Interface Index is not. However, on some systems (e.g. > BSDs) the Interface name depends on the NIC vendor, which means that if > a NIC is replaced with another from a different vendor, the Interface > name is likely to change, and therefore the resulting address will change. > > My take would be to replace "Interface Index" in the expression with an > abstract "Interface_ID", and then explain that "Interfae_ID" can be > either the Interface Index or the Interface name, and include some of > the text above (explaining why an implementation might want to include > one or the other -- i.e., if your Interface Indexes are stable, use > them. Else use the Interface name). > > Thoughts? Mmm I think that there is a tension in I-Ds such as this between the purist IETF approach - if it does not impact interoperability, then it has no place in an IETF RFC - and the pragmatic - end users want a simple set of rules to follow that just work without having to understand the ins and outs of standard making (I have met a lot of the latter outside the IETF). One compromise is to put the pragmatic in a non-Normative Appendix. 'if your Interface Indexes are stable'? I imagine most people assume that they are (even if the choice of values made by a manufacturer seems bizarre). I have encountered this several times but even so, might have forgotten if it had not surfaced on netmod last month. So do we then explain which systems may have unstable addresses? So yes, I like an abstract Interface_ID but it needs some explanation, best in an Appendix, but how far we go into unstable indices, I am unsure. (I am also unsure how the index value which appears in the API, as referenced in the I-D, relates to the ifIndex value in a MIB - I am familiar with the latter, but do not know enough of IPv6 to know its relationship to the former). Tom Petch > > Thanks! > -- > Fernando Gont > SI6 Networks > e-mail: fg...@si6networks.com > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 > > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
