| Message ID | 1448884508-5235-1-git-send-email-bjorn@mork.no |
|---|---|
| State | RFC, archived |
| Delegated to: | David Miller |
| Headers | show |
Hi, 2015-11-30 20:55 GMT+09:00 Bjørn Mork <bjorn@mork.no>: > 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? > > > > Bjørn > > > net/ipv6/addrconf.c | 14 ++++++++++++-- > 1 file changed, 12 insertions(+), 2 deletions(-) > > diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c > index d84742f003a9..6cf3cae691a5 100644 > --- a/net/ipv6/addrconf.c > +++ b/net/ipv6/addrconf.c > @@ -53,6 +53,7 @@ > #include <linux/if_arp.h> > #include <linux/if_arcnet.h> > #include <linux/if_infiniband.h> > +#include <linux/random.h> > #include <linux/route.h> > #include <linux/inetdevice.h> > #include <linux/init.h> > @@ -2026,6 +2027,13 @@ static int addrconf_ifid_ip6tnl(u8 *eui, struct net_device *dev) > return 0; > } > > +static int addrconf_ifid_random(u8 *eui, struct net_device *dev) > +{ > + get_random_bytes(eui, 8); > + eui[0] |= 0x02; > + return 0; > +} > + Since random identifier is locally assigned, drop the global bit instead if setting it. --yoshfuji -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
吉藤英明 <hideaki.yoshifuji@miraclelinux.com> writes: >>> +static int addrconf_ifid_random(u8 *eui, struct net_device *dev) >> +{ >> + get_random_bytes(eui, 8); >> + eui[0] |= 0x02; >> + return 0; >> +} >> + > > Since random identifier is locally assigned, drop the global bit > instead if setting it. Yes, definitely. Thanks. I'm considering reusing __ipv6_regen_rndid() which already does this correctly, and also avoids some locally assigned addresses with special meanings. Another issue with the initial RFC is that every prefix will have a new random ifid, which isn't necessarily what the users expect. I wonder if it would be acceptable to abuse the rndid field for storing a "permanent" random ifid? Bjørn -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi, Bjørn Mork wrote: > 吉藤英明 <hideaki.yoshifuji@miraclelinux.com> writes: > >>>> +static int addrconf_ifid_random(u8 *eui, struct net_device *dev) >>> +{ >>> + get_random_bytes(eui, 8); >>> + eui[0] |= 0x02; >>> + return 0; >>> +} >>> + >> >> Since random identifier is locally assigned, drop the global bit >> instead if setting it. > > Yes, definitely. Thanks. I'm considering reusing __ipv6_regen_rndid() > which already does this correctly, and also avoids some locally assigned > addresses with special meanings. > > Another issue with the initial RFC is that every prefix will have a new > random ifid, which isn't necessarily what the users expect. I wonder if > it would be acceptable to abuse the rndid field for storing a "permanent" > random ifid? Well, I think we should introduce ifid in inet6_dev. After that we could use it from other ifid methods. --yoshfuji > > > Bjørn >
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 -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hannes Frederic Sowa <hannes@stressinduktion.org> writes: > 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 for commenting on this. Yes, the stable privacy addresses looks like they will solve this and other problems. But enabling them require an adminstrator action. After looking more at addrconf, I started wondering if we couldn't abuse ipv6_generate_stable_address() for this purpose? We could add a new addr_gen_mode which would trigger automatic generation of a secret if stable_secret is uninitialized. This would be good enough to ensure stability until the interface is destroyed. And it would still allow the adminstrator to select IN6_ADDR_GEN_MODE_STABLE_PRIVACY by entering a new secret. Bjørn -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hello, On Thu, Dec 3, 2015, at 20:29, Bjørn Mork wrote: > Hannes Frederic Sowa <hannes@stressinduktion.org> writes: > > > 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 for commenting on this. Yes, the stable privacy addresses looks > like they will solve this and other problems. But enabling them require > an adminstrator action. > > After looking more at addrconf, I started wondering if we couldn't abuse > ipv6_generate_stable_address() for this purpose? We could add a new > addr_gen_mode which would trigger automatic generation of a secret if > stable_secret is uninitialized. This would be good enough to ensure > stability until the interface is destroyed. And it would still allow > the adminstrator to select IN6_ADDR_GEN_MODE_STABLE_PRIVACY by entering > a new secret. I am fine with your proposal but I would really like to see it only happen on the per-interface stable_secret instance. Thanks, Hannes -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c index d84742f003a9..6cf3cae691a5 100644 --- a/net/ipv6/addrconf.c +++ b/net/ipv6/addrconf.c @@ -53,6 +53,7 @@ #include <linux/if_arp.h> #include <linux/if_arcnet.h> #include <linux/if_infiniband.h> +#include <linux/random.h> #include <linux/route.h> #include <linux/inetdevice.h> #include <linux/init.h> @@ -2026,6 +2027,13 @@ static int addrconf_ifid_ip6tnl(u8 *eui, struct net_device *dev) return 0; } +static int addrconf_ifid_random(u8 *eui, struct net_device *dev) +{ + get_random_bytes(eui, 8); + eui[0] |= 0x02; + return 0; +} + static int ipv6_generate_eui64(u8 *eui, struct net_device *dev) { switch (dev->type) { @@ -2047,6 +2055,8 @@ static int ipv6_generate_eui64(u8 *eui, struct net_device *dev) return addrconf_ifid_ieee1394(eui, dev); case ARPHRD_TUNNEL6: return addrconf_ifid_ip6tnl(eui, dev); + case ARPHRD_NONE: + return addrconf_ifid_random(eui, dev); } return -1; } @@ -3069,8 +3079,8 @@ static void addrconf_dev_config(struct net_device *dev) (dev->type != ARPHRD_IEEE802154) && (dev->type != ARPHRD_IEEE1394) && (dev->type != ARPHRD_TUNNEL6) && - (dev->type != ARPHRD_6LOWPAN)) { - /* Alas, we support only Ethernet autoconfiguration. */ + (dev->type != ARPHRD_6LOWPAN) && + (dev->type != ARPHRD_NONE)) { return; }
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? Bjørn net/ipv6/addrconf.c | 14 ++++++++++++-- 1 file changed, 12 insertions(+), 2 deletions(-)