Hello,

On Mon, Nov 30, 2015, at 12:55, Bjørn Mork wrote:

Generating a random ifid for devices with no L2 header
at all, allowing such devices to take part in IPv6
autoconfiguration. The tuntap driver is one example of
a driver where such an ifid would be useful.

Note that as there is no persistence, new addresses
will be generated every time an interface is brought up:

 # ip -6 addr show dev tun0
 8: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 state
 UNKNOWN qlen 500
     inet6 fe80::eef2:111c:f270:92ba/64 scope link
        valid_lft forever preferred_lft forever
 # ip link set tun0 down
 # ip link set tun0 up
 # ip -6 addr show dev tun0
 8: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 state
 UNKNOWN qlen 500
     inet6 fe80::eec0:48d0:6b52:8835/64 scope link
        valid_lft forever preferred_lft forever

Signed-off-by: Bjørn Mork <bjorn@mork.no>
---
I'm planning raw-ip support for the qmi_wwan driver.  And
the feedback from primary users (ModemManager++) is that
a headerless netdev is preferred over a fake ethernet
device. The current plan is to model this after 'tun'
devices, using ARPHRD_NONE as type.

But these devices will need an IPv6 link local address for
full SLAAC support.  I am therefore wondering if an approach
like this patch will be acceptable, or if I should look for
some other solution?

I see no problem with the patch as it eases operating those devices. I
would also suggest storing the ifid in the inet6_dev so it does only
change during device creation and destruction. Otherwise I would
recommend to use stable privacy addresses to generate the link local
addresses. EUI-48 based LL creation should hopefully not be used anymore
soon.

Thanks,
Hannes