Message ID | 1528062874-19250-1-git-send-email-subashab@codeaurora.org |
---|---|
State | Changes Requested, archived |
Delegated to: | David Miller |
Headers | show |
Series | [net-next] net: ipv6: Generate random IID for addresses on RAWIP devices | expand |
Hello, 2018-06-04 6:54 GMT+09:00 Subash Abhinov Kasiviswanathan <subashab@codeaurora.org>: > RAWIP devices such as rmnet do not have a hardware address and > instead require the kernel to generate a random IID for the > temporary addresses. For permanent addresses, the device IID is > used along with prefix received. > > Signed-off-by: Subash Abhinov Kasiviswanathan <subashab@codeaurora.org> > --- > net/ipv6/addrconf.c | 17 ++++++++++++++++- > 1 file changed, 16 insertions(+), 1 deletion(-) > > diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c > index f09afc2..e4c4540 100644 > --- a/net/ipv6/addrconf.c > +++ b/net/ipv6/addrconf.c > @@ -2230,6 +2230,18 @@ static int addrconf_ifid_ip6tnl(u8 *eui, struct net_device *dev) > return 0; > } > > +static int addrconf_ifid_rawip(u8 *eui, struct net_device *dev) > +{ > + struct in6_addr lladdr; > + > + if (ipv6_get_lladdr(dev, &lladdr, IFA_F_TENTATIVE)) > + get_random_bytes(eui, 8); Please be aware of I/G bit and G/L bit. --yoshfuji
From: Subash Abhinov Kasiviswanathan <subashab@codeaurora.org> Date: Sun, 3 Jun 2018 15:54:34 -0600 > RAWIP devices such as rmnet do not have a hardware address and > instead require the kernel to generate a random IID for the > temporary addresses. For permanent addresses, the device IID is > used along with prefix received. > > Signed-off-by: Subash Abhinov Kasiviswanathan <subashab@codeaurora.org> Please address yoshfuji's feedback, thank you.
On Mon, Jun 4, 2018 at 8:51 AM 吉藤英明 <hideaki.yoshifuji@miraclelinux.com> wrote: > > > + if (ipv6_get_lladdr(dev, &lladdr, IFA_F_TENTATIVE)) > > + get_random_bytes(eui, 8); > > Please be aware of I/G bit and G/L bit. Actually, I think this is fine. RFC 7136 clarified this, and says: ====== Thus, we can conclude that the value of the "u" bit in IIDs has no particular meaning. In the case of an IID created from a MAC address according to RFC 4291, its value is determined by the MAC address, but that is all. [...] Specifications of other forms of 64-bit IIDs MUST specify how all 64 bits are set, but a generic semantic meaning for the "u" and "g" bits MUST NOT be defined. However, the method of generating IIDs for specific link types MAY define some local significance for certain bits. In all cases, the bits in an IID have no generic semantics; in other words, they have opaque values. In fact, the whole IID value MUST be viewed as an opaque bit string by third parties, except possibly in the local context. ====== That said - we already have a way to form all-random IIDs: IN6_ADDR_GEN_MODE_RANDOM. Can't you just ensure that links of type ARPHRD_RAWIP always use IN6_ADDR_GEN_MODE_RANDOM? That might lead to less special-casing.
> Actually, I think this is fine. RFC 7136 clarified this, and says: > > ====== > Thus, we can conclude that the value of the "u" bit in IIDs has no > particular meaning. In the case of an IID created from a MAC > address > according to RFC 4291, its value is determined by the MAC address, > but that is all. > [...] > Specifications of other forms of 64-bit IIDs MUST specify how all 64 > bits are set, but a generic semantic meaning for the "u" and "g" > bits > MUST NOT be defined. However, the method of generating IIDs for > specific link types MAY define some local significance for certain > bits. > > In all cases, the bits in an IID have no generic semantics; in other > words, they have opaque values. In fact, the whole IID value MUST > be > viewed as an opaque bit string by third parties, except possibly in > the local context. > ====== > > That said - we already have a way to form all-random IIDs: > IN6_ADDR_GEN_MODE_RANDOM. Can't you just ensure that links of type > ARPHRD_RAWIP always use IN6_ADDR_GEN_MODE_RANDOM? That might lead to > less special-casing. Hi Lorenzo In v2 of this patchset, I used addrconf_ifid_ip6tnl() similar to IP6 Tunnels / VTI6, so I didnt need that way of generating the IID. addrconf_ifid_ip6tnl() also provides fixed IIDs during the lifetime of the net device while IN6_ADDR_GEN_MODE_RANDOM generates different addresses.
diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c index f09afc2..e4c4540 100644 --- a/net/ipv6/addrconf.c +++ b/net/ipv6/addrconf.c @@ -2230,6 +2230,18 @@ static int addrconf_ifid_ip6tnl(u8 *eui, struct net_device *dev) return 0; } +static int addrconf_ifid_rawip(u8 *eui, struct net_device *dev) +{ + struct in6_addr lladdr; + + if (ipv6_get_lladdr(dev, &lladdr, IFA_F_TENTATIVE)) + get_random_bytes(eui, 8); + else + memcpy(eui, lladdr.s6_addr + 8, 8); + + return 0; +} + static int ipv6_generate_eui64(u8 *eui, struct net_device *dev) { switch (dev->type) { @@ -2252,6 +2264,8 @@ static int ipv6_generate_eui64(u8 *eui, struct net_device *dev) case ARPHRD_TUNNEL6: case ARPHRD_IP6GRE: return addrconf_ifid_ip6tnl(eui, dev); + case ARPHRD_RAWIP: + return addrconf_ifid_rawip(eui, dev); } return -1; } @@ -3286,7 +3300,8 @@ static void addrconf_dev_config(struct net_device *dev) (dev->type != ARPHRD_IP6GRE) && (dev->type != ARPHRD_IPGRE) && (dev->type != ARPHRD_TUNNEL) && - (dev->type != ARPHRD_NONE)) { + (dev->type != ARPHRD_NONE) && + (dev->type != ARPHRD_RAWIP)) { /* Alas, we support only Ethernet autoconfiguration. */ return; }
RAWIP devices such as rmnet do not have a hardware address and instead require the kernel to generate a random IID for the temporary addresses. For permanent addresses, the device IID is used along with prefix received. Signed-off-by: Subash Abhinov Kasiviswanathan <subashab@codeaurora.org> --- net/ipv6/addrconf.c | 17 ++++++++++++++++- 1 file changed, 16 insertions(+), 1 deletion(-)