At some point, in some teaching material (from Linux Foundation) on Linux that I came across, the following is mentioned:

ip command is more versatile and more efficient than ifconfig because it uses netlink sockets rather than ioctl system calls.

Can anyone elaborate a bit on this because I cannot understand what's going on under the hood?

P.S. I am aware of this topic on those tools but it does not address this specific difference on how they operate

The ifconfig command on operating systems such as FreeBSD and OpenBSD was updated in line with the rest of the operating system. It nowadays can configure all sorts of network interface settings on those operating systems, and handle a range of network protocols. The BSDs provide ioctl() support for these things.

This did not happen in the Linux world. There are, today, three ifconfig commands:

• 
  ifconfig from GNU inetutils

  jdebp % inetutils-ifconfig -l
  enp14s0 enp15s0 lo
  jdebp % inetutils-ifconfig lo
  lo Link encap:Local Loopback
   inet addr:127.0.0.1 Bcast:0.0.0.0 Mask:255.0.0.0
   UP LOOPBACK RUNNING MTU:65536 Metric:1
   RX packets:9087 errors:0 dropped:0 overruns:0 frame:0
   TX packets:9087 errors:0 dropped:0 overruns:0 carrier:0
   collisions:0 txqueuelen:1000
   RX bytes:51214341 TX bytes:51214341
  jdebp %

  
  


• ifconfig from NET-3 net-tools

  jdebp % ifconfig -l
  ifconfig: option -l' not recognised.
  ifconfig:--help' gives usage information.
  jdebp % ifconfig lo
  lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
   inet 127.0.0.1 netmask 255.0.0.0
   inet6 ::1 prefixlen 128 scopeid 0x10<host>
   inet6 ::2 prefixlen 128 scopeid 0x80<compat,global>
   inet6 fe80:: prefixlen 10 scopeid 0x20<link>
   loop txqueuelen 1000 (Local Loopback)
   RX packets 9087 bytes 51214341 (48.8 MiB)
   RX errors 0 dropped 0 overruns 0 frame 0
   TX packets 9087 bytes 51214341 (48.8 MiB)
   TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
  jdebp %

  
  


• ifconfig from (version 1.40 of) the nosh toolset

  jdebp % ifconfig -l
  enp14s0 enp15s0 lo
  jdebp % ifconfig lo
  lo
   link up loopback running
   link address 00:00:00:00:00:00 bdaddr 00:00:00:00:00:00 
   inet4 address 127.0.0.1 prefixlen 8 bdaddr 127.0.0.1 
   inet4 address 127.53.0.1 prefixlen 8 bdaddr 127.255.255.255 
   inet6 address ::2 scope 0 prefixlen 128 
   inet6 address fe80:: scope 1 prefixlen 10 
   inet6 address ::1 scope 0 prefixlen 128
  jdebp % sudo ifconfig lo inet4 127.1.0.2 alias
  jdebp % sudo ifconfig lo inet6 ::3/128 alias
  jdebp % ifconfig lo
  lo
   link up loopback running
   link address 00:00:00:00:00:00 bdaddr 00:00:00:00:00:00 
   inet4 address 127.0.0.1 prefixlen 8 bdaddr 127.0.0.1 
   inet4 address 127.1.0.2 prefixlen 32 bdaddr 127.1.0.2 
   inet4 address 127.53.0.1 prefixlen 8 bdaddr 127.255.255.255 
   inet6 address ::3 scope 0 prefixlen 128 
   inet6 address ::2 scope 0 prefixlen 128 
   inet6 address fe80:: scope 1 prefixlen 10 
   inet6 address ::1 scope 0 prefixlen 128 
  jdebp % 

  
  

As you can see, the GNU inetutils and NET-3 net-tools ifconfigs have some marked deficiencies, with respect to IPv6, with respect to interfaces that have multiple addresses, and with respect to functionality like -l.

The IPv6 problem is in part some missing code in the tools themselves. But in the main it is caused by the fact that Linux does not (as other operating systems do) provide IPv6 functionality through the ioctl() interface. It only lets programs see and manipulate IPv4 addresses through the networking ioctl()s.

Linux instead provides this functionality through a different interface, send() and recv() on a special, and somewhat odd, address family of sockets, AF_NETLINK.

The GNU and NET-3 ifconfigs could have been adjusted to use this new API. The argument against doing so was that it was not portable to other operating systems, but these programs were in practice already not portable anyway so that was not much of an argument.

But they weren't adjusted, and remain as aforeshown to this day. (Some people worked on them at various points over the years, but the improvements, sad to say, never made it into the programs. For example: Bernd Eckenfels never accepted a patch that added some netlink API capability to NET-3 net-tools ifconfig, 4 years after the patch had been written.)

Instead, some people completely reinvented the toolset as an ip command, which used the new Linux API, had a different syntax, and combined several other functions behind a fashionable command subcommand-style interface.

I needed an ifconfig that had the command-line syntax and output style of the FreeBSD ifconfig (which neither the GNU nor the NET-3 ifconfig has, and which ip most certainly does not have). So I wrote one. As proof that one could write an ifconfig that uses the netlink API on Linux, it does.

So the received wisdom about ifconfig, such as what you quote, is not really true any more. It is now untrue to say that "ifconfig does not use netlink.". The blanket that covered two does not cover three.

It has always been untrue to say that "netlink is more efficient". For the tasks that one does with ifconfig, there isn't really much in it when it comes to efficiency between the netlink API and the ioctl() API. One makes pretty much the same number of API calls for any given task.

Indeed, each API call is two system calls in the netlink case, as opposed to one in the ioctl() system. And arguably the netlink API has the disadvantage that on a heavily-used system it explicitly incorporates the possibility of the tool never receiving an acknowledgement message informing it of the result of the API call.

It is, furthermore, untrue to say that ip is "more versatile" than the GNU and NET-3 ifconfigs because it uses netlink. It is more versatile because it does more tasks, doing things in one big program that one would do with separate programs other than ifconfig. It is not more versatile simply by dint of the API that it uses internally for performing those extra tasks. There's nothing inherent to the API about this. One could write an all-in-one tool that used the FreeBSD ioctl() API, for example, and equally well state that it is "more versatile" than the individual ifconfig, route, arp, and ndp commands.

One could write route, arp, and ndp commands for Linux that used the netlink API, too.

Further reading

• Jonathan de Boyne Pollard (2019). ifconfig. nosh Guide. Softwares.


• Eduardo Ferro (2009-04-16). ifconfig: reports wrong ip address / initial patch. Debian bug #359676.

The standard ifconfig we have in many distributions is deprecated for several reasons. Talks in a outdated and limited way with the kernel, and in fact, does not understand anymore all the network configurations. You won't be able to manipulate some network configurations such ifconfig versions that you are able to do with ip. In addition, the ifconfig support for network namespaces is limited.

As an anecdotal tale, I found interface IP alias that are only visible in ip and not in SuSE ifconfig.

As for the differences under the hood: From ifconfig vs ip: What’s Difference and Comparing Network Configuration

Although ip might seem a bit complex at first site but it is much
broader in functionality than ifconfig. It is functionally organized
on two layers of Networking Stack i.e. Layer 2 (Link Layer), Layer 3
(IP Layer) and does the work of all the above mentioned commands from
net-tools package.

While ifconfig mostly displays or modifies the interfaces of a system,
this command is capable of doing following tasks:

• Displaying or Modifying Interface properties.




• Adding, Removing ARP Cache entries along creating new Static ARP entry
  for a host.




• Displaying MAC addresses associated with all the interfaces.




• Displaying and modifying kernel routing tables.

One of the main highlight which separates it from its ancient
counterpart ifconfig is that latter uses ioctl for network
configuration, which is a less appreciated way of interaction with
kernel while former takes advantage of netlink socket mechanism for
the same which is a much more flexible successor of ioctl for
inter-communication between kernel and user space using rtnetlink
(which adds networking environment manipulation capability).

About the use/advantages of netlink: From LJ - Kernel Korner - Why and How to Use Netlink Socket

Netlink socket is a special IPC used for transferring information
between kernel and user-space processes. It provides a full-duplex
communication link between the two by way of standard socket APIs for
user-space processes and a special kernel API for kernel modules.
Netlink socket uses the address family AF_NETLINK.

.....

Why do the above features use netlink instead of system calls, ioctls
or proc filesystems for communication between user and kernel worlds?
It is a nontrivial task to add system calls, ioctls or proc files for
new features; we risk polluting the kernel and damaging the stability
of the system. Netlink socket is simple, though: only a constant, the
protocol type, needs to be added to netlink.h. Then, the kernel module
and application can talk using socket-style APIs immediately.

....

Netlink socket is a flexible interface for communication between
user-space applications and kernel modules. It provides an easy-to-use
socket API to both applications and the kernel. It provides advanced
communication features, such as full-duplex, buffered I/O, multicast
and asynchronous communication, which are absent in other
kernel/user-space IPCs.