Hi Fernando,
----- Original Message ----- > From: Fernando Gont <[email protected]> > To: Mark Smith <[email protected]> > Cc: Ray Hunter <[email protected]>; "[email protected]" > <[email protected]>; Brian Haberman <[email protected]>; > "[email protected]" <[email protected]>; RJ Atkinson <[email protected]>; t.petch > <[email protected]> > Sent: Friday, 26 April 2013 9:01 AM > Subject: Re: LC comments on stable-privacy-addresses: Interface Index vs. name > > Hi, Mark, > > Thanks so much for your feedback! -- Please find my comments in-line.... > > On 04/25/2013 06:13 PM, Mark Smith wrote: >> >> 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. > > Will do -- I'm now thinking whether I should add one subsection per > argument ("secret key, network_id", etc.), or whether I should list > such > properties in the hanging-text list, or in the prose below the > expression -- thoughts? > I think it might be influenced by what I've suggested below. > > >> 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. > > My undestanding was tht that was how interface indexes were generated -- > but, aparently, they aren't. > I don't think it is specifically defined. For example, I understand Linux just uses an incrementing allocation counter, which is why the order of interface initialisation or insertion matters. On routers etc., this sort of scheme also seems to be common, as they also can have a command which enables persistent indexes, such that they are restored after a reboot, and typically that defaults to off. I have recently come across a scheme which doesn't seem to fit either of these though - the ifindex values are huge numbers, however they don't seem to be persistent by default, as that has to be enabled. > > >> 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. > > I'd argue that this would be a desirable property. My view is that from > a logical point of view, a NIC attached to a different port is a > different interface, and hence it should get a different IPv6 address. > (after all, if swapping a NIC should not result in a different IPv6 > addresses, then this method should not try to generate the same IPv6 > address when the same NIC is "detected"). > So having thought about it for a few days, I still think it would be better, by default, to try to provide a stable private address for the Interface, regardless of how it is attached to the system. Thinking about a model, I think there are 3 components - the system, the modular network interface (hot pluggable or not) and the network it is attached to. I think IPv6 addresses are assigned at the point where the network interface connects to the network, rather than where the network interface connects to the system. So under normal and common circumstances, if the same interface is plugged into the same network, I think it should get the same stable privacy address, regardless of whether the network interface is plugged into the same or a different system bus connector (e.g, a different USB port) at the time. I think this would be a bit more consistent with IPv6 addressing model, which says that IPv6 addresses are assigned to interfaces. I think replacing an interface because it is faulty could be treated as a special case. Technically the interface is different, and therefore should get a different stable privacy IPv6 address. However, it is instead inheriting the stable privacy address of the interface it is replacing. I don't think this situation is necessarily indicated just by the new interface being plugged into the same system bus connector as the old one. It could be, however I think that should be enabled by a system switch, similar to how persistent ifindexes are switched on. > > >> 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. > > I'd prefer that the IPv6 address is not bound to any serial number of > MAC address. That of having the resulting IPv6 addresses being > independent of the underlying media is an interesting property. > What I was thinking here was that these sorts of attributes could be used to recognise when a new interface or a previously known interface is plugged into the system. They could be used as inputs (perhaps to a hash) to generate a more generic "Link Layer Interface Identifier" value (e.g. a 32 bit one) that could then be used as an input into your stable privacy address function, instead of using the ifindex. These attributes would only include those that are specific to the interface, not ones that are specific to how the interface is connected to the system, so that e.g., moving the interface to a different USB port wouldn't change the stable privacy IPv6 address. Replacing a faulty interface would mean that the instead of the system using the Link Layer Interface Identifier value that it generates based on the new interface's attributes, it instead substitutes the faulty interface's Link Layer Interface Identifier value into the stable privacy IPv6 address function. It is likely the the system would maintain a database of known interfaces, and one of the fields would be the substitute Link Layer Interface Identifier, used if it has a value. An unknown interface would cause a new entry to be added to this database. Globally MAC addresses by themselves theoretically should be the only attribute necessary to generate a unique Link Layer Interface Identifier, however they're not as unique in practice. So adding other available network interface similar attributes such as product ID, revision number, date of manufacture, serial number, etc., that might also be available would help recognise the same interface. > > >> 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. > > Yep, that's why using the interface name, *for these systems* might be > more appropriate. However, the interface names on *BSD seem to depend on > the vendor name... and hence would vary if a NIC is replaced with > another NIC from a different vendor. > Agree. This is why I think it would be better to use attributes that are "burnt into" the network interface module itself, rather than use attributes that are either generated by the system (e.g. ifindex, interface name), or properties of how the network interface module is attached to the system. > > >> 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. > > mmm... not sure what you mean. -- Could you please elaborate? > So these bridge virtual interfaces are the interfaces that are where the IPv6 addresses are configured/assigned, rather than the physical interfaces that are members of the bridge. They're dynamic, so they won't necessarily have the same ifindex each time, and their name may be chosen by the system operator at the time the bridge and the bridge virtual interface is created, and their MAC address can change dynamically. Is that enough of an explanation? Best regards, Mark. -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
