--- /dev/null
+ Network interface renaming comparison
+ -------------------------------------
+
+INTRODUCTION
+------------
+ The Wireless Tools package includes 'ifrename', a tool to
+rename network interfaces. However, this is not the only solution to
+the problem of renaming network interfaces. This document explain the
+differences between ifrename and the various alternatives.
+ The subject of interface renaming may look simple at first
+glance, and is simple in 95% of the cases, however there are many
+complex scenario and those tools have many features, which explain why
+we need to go in more details than just saying 'tool X is better'.
+
+NAMEIF
+------
+ The tool 'nameif' was designed to rename network
+interfaces. It either loads mapping from the file /etc/mactab or
+accept mapping on the command line.
+ It is part of the net-tools package :
+ http://www.tazenda.demon.co.uk/phil/net-tools/
+
+ Advantages over 'ifrename' :
+ + More widespread, available in very old distributions
+ + simpler/smaller
+ Drawbacks compared to 'ifrename' :
+ - Only support MAC address selector
+ - Does not support hotplug invocation
+ - Does not support module on-demand loading
+ Comments :
+ o The fact that nameif does not support selector other
+than the MAC address is problematic, as USB-NET devices may not have
+MAC addresses and some ethernet/wireless drivers can't query the MAC
+address before 'ifconfig up'.
+ o 'ifrename' was designed as a better 'nameif', and
+its concept is very similar.
+
+IPROUTE
+-------
+ The tool 'ip' can rename network interfaces with the following
+syntax :
+ > ip link set <oldname> name <newname>
+ It is part of the 'iproute' package :
+ http://developer.osdl.org/dev/iproute2/
+
+ Advantages over 'ifrename' :
+ + integrated in 'iproute', which most people need anyway
+ Drawbacks compared to 'ifrename' :
+ - Do not support any selector, must use old interface name
+ - No 'batch' mode, must rename each interface manually
+ Comments :
+ o 'ip' only provide the most basic facility. To use it
+automatically, like in init/hotplug scripts, wrappers adding some
+rules/selector must be written.
+
+DRIVER MODULE PARAMETERS
+------------------------
+ Some network driver have module parameters enabling to specify
+the network name of all the devices created by the driver. This is
+driver specific, so you will need to check your driver.
+
+ Advantages over 'ifrename' :
+ + very simple to get configured and running
+ Drawbacks compared to 'ifrename' :
+ - Not universally supported : few drivers do it
+ - Fragmented : each driver does it differently
+ - The only selector available is the driver
+ Comments :
+ o This method was never popular with the kernel
+people, and this feature is being removed from driver that use to
+include it.
+
+UDEV
+----
+ The package 'udev' include facility to rename network
+interfaces, with rules such as :
+ KERNEL="eth*", SYSFS{address}="00:52:8b:d5:04:48", NAME="lan"
+ This is part of the udev package :
+ http://www.kernel.org/pub/linux/utils/kernel/hotplug/udev.html
+
+ Advantages over 'ifrename' :
+ + integrated into 'udev'
+ + simpler to setup if 'udev' is already properly setup
+ Drawbacks compared to 'ifrename' :
+ - Less selectors that 'ifrename'
+ - Require kernel 2.6.X or later with sysfs support
+ - Do no support non-hotplug interfaces
+ - Require 'udev', not everybody uses it (static /dev, devfs)
+ - Does not support module on-demand loading
+ Comments :
+ o 'udev' support many selectors, basically all those
+present in 'sysfs', even if the documentation only show instructions
+to use the MAC address (which is problematic with virtual devices some
+drivers - see above). 'ifrename' can also use all selectors present in
+'sysfs' (like 'udev'), plus some other selectors not present in sysfs
+that were found to be useful.
+ o Not all interfaces are managed by hotplug. All
+virtual devices, such as tunnels and loopbacks, are not associated
+with a hardware bus, and therefore are not managed by hotplug. All
+driver compiled statically into the kernel are not managed by
+hotplug. 'udev' can't deal with those devices.
+ o It is common practice on embedded system to use a
+static /dev and not 'udev' to save space and boot time. And to not use
+hotplug for the same reasons.
+ o 'ifrename' could be better integrated in 'udev', I don't foresee any technical issues.
+
+SELECTOR AWARE NETWORK SCRIPTS
+------------------------------
+ Another method is to not rename the interface at all, and make
+the various network script selector aware. The basic idea is to simply
+ignore the interface name and have all the network scripts based on
+selectors.
+ The main example is the original Pcmcia network scripts. They
+allow you to configure an interface directly based on MAC address and
+Pcmcia socket. Another example is the script get-mac-address.sh used
+as a mapping in some Debian configuration. On the other hand, Red-Hat
+and Fedora scripts don't apply, as they wrap around 'nameif'.
+
+ Advantages over 'ifrename' :
+ + usually simpler to setup and understand
+ Drawbacks compared to 'ifrename' :
+ - Less selectors that 'ifrename'
+ - Only work for the scripts, other tools left confused
+ Comments :
+ o This method is conceptually simpler, and works
+well. It eliminates the two steps process of other methods (renaming ;
+configuring).
+ o Unfortunately, this method only apply to the
+specific scripts, and not to the majority of the networking tools
+which are still based on interface name. This means that when the user
+use those other tools, he is left guessing which interface is which.
+ o Distributions never never really embraced this
+method, as they all replaced the original Pcmcia scripts with one
+using the interfacename.
+
+ Have fun...
+
+ Jean
+
OSDN Git Service
