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 <redacted>
---
net/ipv6/addrconf.c | 17 ++++++++++++++++-
1 file changed, 16 insertions(+), 1 deletion(-)
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 <redacted>
---
net/ipv6/addrconf.c | 17 ++++++++++++++++-
1 file changed, 16 insertions(+), 1 deletion(-)
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 <redacted>
From: Lorenzo Colitti <hidden> Date: 2018-06-08 02:52:17
On Mon, Jun 4, 2018 at 8:51 AM 吉藤英明 [off-list ref] wrote:
quoted
+ 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.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project