> Mark Smith <mailto:markzzzsm...@yahoo.com.au> > 25 April 2013 23:13 > Hi Fernando, > > > > I think listing those desired properties would be useful, and then > describing examples of actual interface identifiers that would qualify > if available e.g., persistent ifindex values or persistent interface > names. > > One thing that has occurred to me is the interface identifier > stability you're looking for would probably be provided by deriving > the interface ID from the system connector that is used to attach the > network interface to the system e.g. the PCI slot information. A swap > of a failed interface, despite changing the MAC address, will retain > the same interface ID.
> This gets a bit interesting when thinking about the USB NIC situation. > Plugging the USB NIC into different USB slots would change the > interface ID if the slot is used to assign it a persistent interface > ID. OTOH, the MAC address and other properties of the USB NIC (such as > USB serial number if it has one) would be constant, so they could be > used to create a persistent interface ID for your purposes, despite > the different USB slot used to attach it to the system. Perhaps that > means different buses and/or connectors would need different policies > on interface ID assignment, and that could be mentioned in your Draft. Slippery slope to a rat hole. Spent 20+ years configuring various networking devices, and had various run ins with SNMP ifName, ifIdent, cbQosObjectsIndex etc. (which are similar concepts). IMHO There isn't a single best model. - People might want to maintain the stable-privacy-address even though the physical slot changes. - An operator might want to move the configuration to another physical or logical interface due to a fault in the original interface but maintain config (in which case ifDescr would be a better source of differentiation). - An operator might want to configure up another interface that mirrors the first for hot standby on hardware failure. - Device may not support the concept of interface_ID. - Interface may not have a MAC address. - May be multiple sub-interfaces configured on one physical interface. - Single interface devices without a removable NIC don't need to incorporate the interface_ID at all: there's no gain (so it is only a "MAY") - Devices without permanent storage may find it impossible to maintain an interface_ID other than the MAC address, yet want a stable-privacy-address. - Devices may have their permanent storage wiped. I still prefer the text I proposed blow (although feel free to improve it) "an Interface_ID is an implementation-dependent identifier associated with a particular interface on the local node, which is generally time invariant over the long-term and over system reboots. The Interface_ID may be used to assist efficient generation of unique stable-privacy-addresses, especially in situations where multiple interfaces on a single node may be configured using the same L3 Prefix. If the Interface_ID does change for whatever reason, this would obviously undermine the time-invariance of the resulting stable-privacy-addresses." > > As another example of a convention, it seems that Fedora has adopted a > convention of naming wired ethernet interfaces based on whether > they're attached to the motherboard (e.g, em0) or a PCI slot / port > and then virtual function if it has one (e.g. p4p1), so they're > persistent across boots or replacement. Yet they don't apply that to > PCI attached wifi interfaces, which are still called wlanX. > > You might also want to briefly cover persistent interface IDs for > virtual interfaces e.g, bridge virtual interfaces. Their only constant > identifier may be their name - under Linux for example, they seem to > use the lowest numeric MAC address of the member interfaces, which can > change if a new interface is added or the lowest MAC address interface > is removed. > > <snip> > > Regards, > Mark. > Fernando Gont <mailto:fg...@si6networks.com> > 25 April 2013 18:47 > Hi, Ray, > > On 04/25/2013 11:21 AM, Ray Hunter wrote: >> Since both "Interface_Index" and "Interface name" are anyway both >> implementation dependent, why would you need to precisely standardise >> the exact meaning, or the exact source of the information? AFAICS this >> wouldn't significantly affect inter-op, or protocol operation. > > Their implementation (e.g. namespace) are implementation-dependent. > Their properties may not. > > I don't care about the source of information as long as it meets the > goal. Ideally, the I-D: > > * Should be constant across system bootstrap sequences > * Should be different for each network interface > * Should not change when the NIC is replaced > > The first to properties are needed for the "stability" properties of > this scheme. The last one is needed such that the IPv6 address doesn't > change when a NIC is replaced (I hear lots of people do not use SLAAC > because of this). > > > >> I therefore agree with your proposal that the text should define an >> abstract "Interface_ID" and suggest that you define "an Interface_ID is >> an implementation-dependent identifier associated with a particular >> interface on the local node, which is generally invariant over the >> long-term and over system reboots. The Interface_ID may be used to >> assist efficient generation of unique stable-privacy-addresses, >> especially in situations where multiple interfaces on a single node may >> be configured using the same L3 Prefix. If the Interface_ID does change >> for whatever reason, this would obviously undermine the time-invariance >> of the resulting stable-privacy-addresses." >> >> I don't think you need any more guidance than that. > > If you say just that, many will wonder "Ok, so what should I use for the > Interface_ID?". So I'd probably list the three properties I mentioned > above, and (non-normatively) note that the Interface Index or the > Interface name could be used for this purpose... > > Thanks, > Ray Hunter <mailto:v6...@globis.net> > 25 April 2013 18:21 > Since both "Interface_Index" and "Interface name" are anyway both > implementation dependent, why would you need to precisely standardise > the exact meaning, or the exact source of the information? AFAICS this > wouldn't significantly affect inter-op, or protocol operation. > > I therefore agree with your proposal that the text should define an > abstract "Interface_ID" and suggest that you define "an Interface_ID is > an implementation-dependent identifier associated with a particular > interface on the local node, which is generally invariant over the > long-term and over system reboots. The Interface_ID may be used to > assist efficient generation of unique stable-privacy-addresses, > especially in situations where multiple interfaces on a single node may > be configured using the same L3 Prefix. If the Interface_ID does change > for whatever reason, this would obviously undermine the time-invariance > of the resulting stable-privacy-addresses." > > I don't think you need any more guidance than that. > > regards, > RayH > ------------------------------------------------------------------------ -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
